Support unaligned load/store on more ARM targets

[JF Bastien]

I've attached a patch that should address both of your concerns. It adds
the command-line option, and the defaults stays the same except for ARMv7+
Linux and PNaCl. I also moved the alignment test away from fast-isel.ll
into its own file, and added invocations for each of these use cases. That
allowed me to also rename some of the test functions to be more descriptive.

Please take a look and let me know if this new change does what you would
expect.


Comments below are separate from the review...

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...
>

I think I understand something: ARM is growing out of its typically
embedded roots, and I currently care about LLVM's ARM as "consumer ARMv7a",
whereas you want to also please other users who have typically been closer
to the system. Would it be worth making a distinction between A/R/M
profiles at some later time, or something along those lines?


"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.
>

I'm sorry my comment was misleading. What I mean is: Apple has a great
advantage here, and using that knowledge to get the best performance is the
right thing to do. What I'm trying to do at the moment is to see what can
be reused for other targets (I don't want to just fix PNaCl). I don't see
this as adversarial at all, quite the opposite I greatly appreciate the
work that's been put in!



> 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.
>

Shouldn't this just be:
  mrc p15, 0, r0, c1, c0, 0
  orr r0, r0, #2
  mcr p15, 0, r0, c1, c0, 0
?



> 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.
>

Agreed that as-is my previous change should, at the minimum, have been
prominently in release notes, and most probably at some major milestone. I
hope the attached change is more agreeable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130516/60923ff8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm-unaligned-2.patch
Type: application/octet-stream
Size: 13708 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130516/60923ff8/attachment.obj>