[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <98e7af705bf54b88a99dfec46308bb7a@AcuMS.aculab.com>
Date: Sat, 8 May 2021 14:18:56 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Arnd Bergmann' <arnd@...nel.org>,
"'linux-arch@...r.kernel.org'" <linux-arch@...r.kernel.org>
CC: 'Linus Torvalds' <torvalds@...ux-foundation.org>,
'Vineet Gupta' <vgupta@...opsys.com>,
'Arnd Bergmann' <arnd@...db.de>,
"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC 12/12] asm-generic: simplify asm/unaligned.h
From: David Laight
> Sent: 08 May 2021 12:03
>
> From: Arnd Bergmann
> > Sent: 07 May 2021 23:08
> >
> > The get_unaligned()/put_unaligned() implementations are much more complex
> > than necessary, now that all architectures use the same code.
> >
> ...
> > +#define __get_unaligned_t(type, ptr) ({ \
> > + const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \
> > + __pptr->x; \
> > +})
>
> I thought gcc was likely to track through the alignment of the
> variable holding the source pointer (through any (void *) casts
> implied by inlined function calls) through to the pointer used
> for the actual access - so it would tend to issue a single
> instruction that assumed an aligned address.
>
> I know that has caused grief trying to copy unaligned data
> to an aligned structure.
>
> Possibly adding:
> asm ("" :: "+r" (__pptr)) );
> in the middle stops that assumption without generating any code.
That is the wrong asm.
You need the one where an input operand and output operand
share the same register and use it for the assignment.
I've been trying to get godbolt to do something useful.
But it seems to be stuck in C++ mode and is missing something like
sparc which definitely doesn't do misaligned accesses.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists