Andrew Trick
2013-Jan-21 19:49 UTC
[LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
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 >
Chandler Carruth
2013-Jan-21 20:37 UTC
[LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
On Mon, Jan 21, 2013 at 11:49 AM, Andrew Trick <atrick at apple.com> wrote:> 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. >My proposed resolution: - If the tests are target independent, delete the triple. - If they aren't, sink them to a target-specific subdirectory so they're skipped in the absence of the target being built. - Make a triple an error if there is not support for that target. -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130121/0ce1e0bb/attachment.html>
Renato Golin
2013-Jan-21 21:19 UTC
[LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
On 21 January 2013 20:37, Chandler Carruth <chandlerc at google.com> wrote:> My proposed resolution: > - If the tests are target independent, delete the triple. > - If they aren't, sink them to a target-specific subdirectory so they're > skipped in the absence of the target being built. > - Make a triple an error if there is not support for that target.+1 --renato
Maybe Matching Threads
- [LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
- [LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
- [LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
- [LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
- [LLVMdev] Patch for Transform/LoopStrengthReduction/post-inc-icmpzero.ll test-failure