[LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll

Mon Jan 21 11:49:11 PST 2013

Moving to llvmdev...

On Jan 21, 2013, at 11:37 AM, Nadav Rotem <nrotem at apple.com> wrote:

> Hi Manish, 
> 
> Thank you for looking at this. Recently opt started using the "-mtriple" command line flag to initialize the TargetMachine for IR-level transformations that use it. Currently only the following passes are using this feature: LSR, LowerSwitch, BBVectorizer and LoopVectorizer. If you look at the tests in LoopVectorize you will see that the target-dependent tests are in target-dependent directories.

The tests in the platform directories are fine. The question is what to do about all the tests in target-independent directories that have "target triple" in the bitcode. These tests don't use -mtriple. Instead, their behavior changes in subtle ways depending on which targets are built. It's certainly a confusing situation.

-Andy

> 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
>> test-case
>> is not a supported target for opt/clang/llvm. In this case, opt doesn't thow
>> an
>> error and hence, later in LSR the NoTTI::isLegalAddressingMode is called
>> which
>> results in the different output.
>> 
>> The clang-native-arm build-bot builds clang with ARM being the only
>> supported
>> target[1]. This is the reason the failure occured only on this build-bot.
>> The
>> problem can be reproduced on x86-hosted clang, if you only build it with
>> only
>> ARM as the supported target.
>> 
>> I think this problem is responsible for other failures on non-x86
>> build-bots.
>> 
>> There a few possible solutions to this problem, but I am not sure which one
>> is
>> 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
>> build-bots.
>> 
>> (c) Modify the tests to cope with the case when the specified target is not
>>   available.
>> 
>> Let me know what do you think? I would be glad to be involved in defining a
>> proper
>> solution in this case. I am happy to open a PR if you think is the best way
>> to
>> resolve this issue.
>> 
>> Regards,
>> Manish
>> 
>> 
>> [1] Configure command:
>> /home/buildslave/slave_as-bldslv1/clang-native-arm-cortex-a9/llvm/configure
>> --disable-bindings --build=armv7l-unknown-linux-gnueabihf
>> --host=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
>> --prefix=/home/buildslave/slave_as-bldslv1/clang-native-arm-cortex-a9/None
>> --enable-optimized --enable-assertions
>> 
>> 
>>> -----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 -
>>> /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
>>> 
>>> Manish,
>>> 
>>> 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.
>>> 
>>> -Andy
>>> 
>>> On Jan 15, 2013, at 11:45 AM, Manish Verma <Manish.Verma at arm.com>
>>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> 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
>>> ARM
>>>> native opt, and the output generated by the release version of x86
>>> opt.
>>>> 
>>>> - 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-
>>> icmpzero.arm.opt.ll
>>>> is different the other two files.
>>>> 
>>>> My setup is also fairly similar to Renato's. The ARM native opt is
>>> built
>>>> 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
>>> with
>>>> autoconf to be sure.
>>>> 
>>>> 
>>>> Manish
>>>> 
>>>>> -----Original Message-----
>>>>> From: Dmitri Gribenko [mailto:gribozavr at gmail.com]
>>>>> Sent: 15 January 2013 19:21
>>>>> To: Renato Golin
>>>>> Cc: Rafael Espíndola; llvm-commits at cs.uiuc.edu for LLVM; Manish
>>> Verma
>>>>> Subject: Re: [llvm-commits] [llvm] r172534 -
>>>>> /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-
>>> icmpzero.ll
>>>>> 
>>>>> On Tue, Jan 15, 2013 at 9:16 PM, Renato Golin
>>>>> <rengolin at systemcall.org> wrote:
>>>>>> On 15 January 2013 18:55, Dmitri Gribenko <gribozavr at gmail.com>
>>>>> wrote:
>>>>>>>> Back to the issue at hand, I couldn't find any difference on
>>> the
>>>>>>>> outputs on x86_64, A9 and A15, (literally, identical outputs),
>>>>> which
>>>>>>>> shows that the issue has nothing to do with ARM and the test
>>>>> should
>>>>>>>> also be failing on other architectures as of r171697-ish.
>>>>>>>> 
>>>>>>>> All outputs had:
>>>>>>>> 
>>>>>>>> %4 = sub i64 %sub.ptr.lhs.cast, %sub.ptr.rhs.cast
>>>>>>> 
>>>>>>> OK, but the outputs are different *now*.
>>>>>> 
>>>>>> And why I asked if it shouldn't be failing on x86 as well, but it
>>>>> seems not:
>>>>>> 
>>>>>> http://lab.llvm.org:8011/builders/llvm-x86_64-ubuntu/builds/6935
>>>>>> 
>>>>>> That's after r171697 and before 172534, so it *should* be
>>> failing,
>>>>> but
>>>>>> it didn't.
>>>>>> 
>>>>>> Don't ask me why not. As far as I can see, it should fail on all
>>>>>> architectures. The only differences between my Intel binaries and
>>>>> my
>>>>>> ARM  ones is that I used CMake to build the Intel ones and
>>> autoconf
>>>>> on
>>>>>> ARM ones, and I'm building outside the tree, when the buildbots
>>> are
>>>>>> not.
>>>>> 
>>>>> So what is the difference between outputs on ARM and x86 right
>>> now?
>>>>> 
>>>>> Dmitri
>>>>> 
>>>>> --
>>>>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>>>>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>>>> <post-inc-icmpzero.arm.opt.ll><post-inc-
>>> icmpzero.arm.debug.ll><post-inc-
>>> icmpzero.x86.opt.ll>_______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 