[LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
atrick at apple.com
Mon Jan 21 11:06:02 PST 2013
Moving to llvm-dev...
On Jan 21, 2013, at 9:07 AM, Manish Verma <manish.verma at arm.com> wrote:
> Hi Andy,
> I have been able track down the reason for the difference in output
> generated by
> opt. The difference is caused when the target triple specified in the
> is not a supported target for opt/clang/llvm. In this case, opt doesn't thow
> error and hence, later in LSR the NoTTI::isLegalAddressingMode is called
> results in the different output.
> The clang-native-arm build-bot builds clang with ARM being the only
> target. This is the reason the failure occured only on this build-bot.
> problem can be reproduced on x86-hosted clang, if you only build it with
> ARM as the supported target.
> I think this problem is responsible for other failures on non-x86
> There a few possible solutions to this problem, but I am not sure which one
> the right solution:
> (a) Error out if *explicitly* specified target-triple is not supported.
> However, this may cause a number of tests to fail on non-X86 hosted
> build-bots as:
> Tests (with explicit target-triple): 1050
> Tests (i686,x86) : 738
> Tests (arm/thumb) : 132
> Tests (powerpc) : 128
> Tests (mips) : 11
> (b) Skip tests if *explicitly* specified target-triple is not supported.
> However, this will result in a number of test being skipped on non-x86
> (c) Modify the tests to cope with the case when the specified target is not
> Let me know what do you think? I would be glad to be involved in defining a
> solution in this case. I am happy to open a PR if you think is the best way
> resolve this issue.
>  Configure command:
> --disable-bindings --build=armv7l-unknown-linux-gnueabihf
> --target=armv7l-unknown-linux-gnueabihf --with-cpu=cortex-a9 --with-fpu=neon
> --with-float=hard --enable-targets=arm --without-llvmgcc --without-llvmgxx
> --enable-optimized --enable-assertions
Thanks for figuring this out Manish.
It seems to me if you don't bother to build a target, it's fair that you won't benefit from tests designed for that target. When I care about testing a change, I build *all* targets. Conversely if you want a test to be platform independent you shouldn't specify a triple.
However, this may be a naive perspective considering the high percentage of tests with triples living in platform-independent test directories.
I'm moving the thread to llvm-dev because I'm sure someone else has thought about this problem. Hopefully they can tell us what to do...
It wouldn't hurt to open a PR to capture the discussion and decision.
>> -----Original Message-----
>> From: Andrew Trick [mailto:atrick at apple.com]
>> Sent: 18 January 2013 22:23
>> To: Manish Verma
>> Cc: 'Dmitri Gribenko'; Renato Golin; llvm-commits at cs.uiuc.edu
>> Subject: Re: [llvm-commits] [llvm] r172534 -
>> For some reason, the arm-hosted LSR does not seem to recognize -1 as
>> a legal address here.
>> I'm baffled at how a fundamental problem would only show up in one
>> test, but as a quick sanity check you can add an unreachable
>> statement to X86TargetLowering::isLegalAddressingMode and make sure
>> LSR is hitting it.
>> I suggest opening a PR.
>> On Jan 15, 2013, at 11:45 AM, Manish Verma <Manish.Verma at arm.com>
>>> I thought it would be my first harmless commit to LLVM. Apparently
>> not! :-)
>>> I am attaching the output generated by debug and release version of
>>> native opt, and the output generated by the release version of x86
>>> - post-inc-icmpzero.arm.debug.ll
>>> - post-inc-icmpzero.arm.opt.ll
>>> - post-inc-icmpzero.x86.opt.ll
>>> Upon diff'ing the files, you can see that post-inc-
>>> is different the other two files.
>>> My setup is also fairly similar to Renato's. The ARM native opt is
>>> using autoconf, while x86 opt is built using CMake. I don't think
>>> this should make a difference, but I am rebuilding my x86 compiler
>>> autoconf to be sure.
More information about the llvm-dev