Support unaligned load/store on more ARM targets

[JF Bastien]

>
> Even more, the change in question actually is a regression for such
>> subtargets. Previously the code generated never trapped and the
>> present one traps. And starting to ask for additional cmdline flag is
>> a bad thing here IMO.
>>
>
> I have to agree with Anton, here. The results of unaligned access is a
> trap and code will fail, independent of the default on power on, boot code
> will set whatever they want and code bare metal code expecting aligned
> access will trap.
>
> Let's be conservative in general and make Linux more performing.
>

I disagree, but my opinion may not align with what's "LLVM-like": I think
the default should be the saner and better-performing option, and that
people writing operating systems, bootloaders and such should have a harder
time (and I've mostly been in the later camp, I know the pain). The current
state of LLVM ARM as I see it is that much has been tuned for Darwin/iOS,
but is turned off out of paranoia for other platforms. This makes it pretty
hard for other platforms (like PNaCl) to actually enjoy LLVM's power.
Unaligned accesses is just one example of this, and I'm trying to fix the
state of things in general, instead of just checking that it works for
PNaCl and calling it a day.

As an example PNaCl doesn't do much that's special (as compared to an OS),
and neither does Linux user-mode, but ARM FastISel plain doesn't work for
them even though there's not actually much preventing me from turning it on.

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?


1. Define subtarget feature. Let's call it "allow unaligned access".
> Make it false by default
> 2. Enable it for Darwin and Linux / PNaCl + v7
> 3. Check for feature, not for subtarget 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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130515/6c451c58/attachment.html>