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

[Manish Verma]

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
>