Support unaligned load/store on more ARM targets

[Renato Golin]

On 16 May 2013 01:18, JF Bastien <jfb at google.com> wrote:

> I disagree, but my opinion may not align with what's "LLVM-like":
>>>
>>
That's not true, especially in the LLVM community. We're all on the same
side, here.


So my rationale is: user-mode code should get the best out of LLVM, and
> system code should have a harder time. Is that the right approach for LLVM?
>

Most of the time, yes. However, we're talking about ARM, here...


Similar to what x86 does for fast unaligned support? Even there x86 does it
> per-hardware target, it's OS-independent. I'd argue that the code I
> submitted was checking for features (v6 and v7), the Darwin check is more
> of a "Apple is vertically integrated and knows that it wouldn't ship a
> silly v6 CPU".
>

This is not an Apple vs. the world issue, be sure of that. LLVM has more
Darwin tweaks than any other just because Apple has historically spent the
bulk of time&money on LLVM, more than any other company or group. Things
are changing recently, but Apple still has a big share of the changes even
today. Hardly surprising.

The problem here is that ARM is not x86. All modern x86 hardware (90's+)
have a BIOS to correctly set-up the best options (have you ever seen BIOS
code? It's horrendous), something that is not true for ARM. OSs like Darwin
and Linux have total control on how to bring the hardware up, and this is
orthogonal to what the hardware is capable or not.

An analogy to x86 world would be if there was an option in the BIOS to
disable unaligned memory access, so the user could change it randomly. If
the kernel had unaligned access in it without any guard, a trap would ensue
and you'd get kernel panic. Large OSs hopefully have ways to work around
any issue a BIOS or an ARM boot code can throw at it, but bare metal
applications (still quite an important realm in ARM-land) does not
necessarily have to.

What Anton was referring to, and I agree, is that *that* kind of code
*will* break with the current change. Adding a new default that traps on
current user code *IS* a regression. What we were saying is that, for the
sake of future folks getting more juice out of LLVM, we'll break much of
the existing bare metal code base, which is not acceptable.

Normally, when changes like that are really important, and I agree with you
that one *IS*, the course of action is to allow a flag to exist for at
least one full release, ask people to use it, document that we *intend* to
make it default on the next release, and given enough interest is put
forward by a larger community than you and me, we change the default and
put big red warnings on the release notes on the next-next release.

GCC has put a lot of work on unaligned access for ARMv7 for the same
reason, but that's mainly Linux realm. However, as has been said many times
on this very list, "what GCC does" is not a valid argument. If the whole
point of LLVM is do "what GCC does", why bother?

In a nutshell, I agree with you that this is an important feature, and must
be always on on Linux (v6/v7) and Darwin (v7), but not as a default for
anything else. At least, not yet.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130516/591c446b/attachment.html>