From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 14 Jul 2012 19:11:59 GMT
Subject: Re: [PATCH maint-1.6.5] block-sha1: avoid unaligned accesses on some big-endian systems
Message-ID: <CA+55aFy+y=TCoJUQarinaduibt4i-46TAuvpp7fsAmjDZj_+3w@mail.gmail.com>
In-Reply-To: <20120714075906.GD3693@burratino>

On Sat, Jul 14, 2012 at 12:59 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Unfortunately, on big-endian architectures, if p is a pointer to
> unsigned int then current gcc assumes it is properly aligned and
> converts this construct to a 32-bit load.

This patch seems to entirely depend on the location of the cast. And
as far as I can tell, that workaround will in turn depend on just what
gets inlined.

My gut feel is that this makes the code uglier (the manual "multiply
by four" being a prime example) while not really even addressing the
problem.

I think a much better approach would be to just mark the unsigned int
data pointer as being unaligned, or add a "get_unaligned()" helper
function (you have to do a structure member and mark the structure
packed, I think - I don't think you can just mark an int pointer
packed). Sure, that's compiler-dependent, but if a compiler does
something like gcc apparently does, it had better support the notion
of unaligned pointers.

And then gcc might actually do the unaligned word read *optimally* on
big-endian architectures, instead of that idiotic byte-at-a-time crap
with shifting.

Anyway, the whole "noticed on alpha" makes no sense, since alpha isn't
even big-endian. So the commit log is insane and misleading too. Alpha
is very much little-endian, but maybe gcc turns the thing into an
unaligned load followed by a bswap.

                      Linus