llvm dev - Jan 2013 - [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
>

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>

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