[llvm] r182877 - Enable FastISel on ARM for Linux and NaCl

[Rafael Espíndola]

Looks like this change is also the one that broke the jit tests on
ARM. It is entirely possible that it is MCJIT that needs to grow
support for what fast isel is producing, but I think we should revert
this for now or at least disable it for MCJIT if there is an easy way.

On 30 May 2013 16:17, JF Bastien <jfb at google.com> wrote:
> Yes, that's how I reproduced the failure. I'm not sure what the right fix
> is, though!
>
>
> On Thu, May 30, 2013 at 1:00 PM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>
>> Note that the test was failing when running on arm linux. I guess you
>> can get it to fail on a x86 host by passing -march=arm to llc.
>>
>> On 30 May 2013 15:57, JF Bastien <jfb at google.com> wrote:
>> > Thanks for catching the failure. I ran make check-all on my x86 box, and
>> > cross-compile to ARM to run the test-suite. The test doesn't specify
>> > -mtriple so it just runs for the current platform.
>> >
>> > It kind of confuses me because AFAICT FPs don't get eliminated on iOS
>> > for
>> > backtracking (see ARMFrameLowering::hasFP), so the debug information has
>> > to
>> > compensate for this. I'm wondering if the test is actually testing what
>> > it
>> > wants to test?
>> >
>> > In any case, adding a triple (and copy/paste of RUN for a few targets)
>> > might
>> > be a good fix, but I'd appreciate some input on whether the test should
>> > be
>> > looking for something different.
>> >
>> >
>> > On Thu, May 30, 2013 at 9:34 AM, Rafael Espíndola
>> > <rafael.espindola at gmail.com> wrote:
>> >>
>> >> looks like this broke 2010-04-19-FramePtr.ll on ARM. I have disable
>> >> fast isel on that test in r182937 to fix the bots. Could you please
>> >> check if it is a bug on fast isel?
>> >>
>> >> Thanks,
>> >> Rafael
>> >
>> >
>
>