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

On Jan 21, 2013, at 3:12 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> On Mon, Jan 21, 2013 at 2:59 PM, Andrew Trick <atrick at apple.com>
wrote:
> 
> On Jan 21, 2013, at 12:37 PM, Chandler Carruth <chandlerc at
google.com> wrote:
> 
>> 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.
> 
> Filed llvm.org/pr15025.
> 
>> - Make a triple an error if there is not support for that target.
> 
> Filed llvm.org/pr15026.
> 
> 
> I assume opt should completely ignore target triple when -mtriple is
provided,
> 
> Yep.
>  
> potentially bypassing the error.
> 
> I would expect opt to error on an invalid '-mtriple' just as it
would for an invalid triple in the IR....
Yes, that's what llc does.

The point is, as long as you specify a valid -mtriple you won't get any
warning about a bad IR target triple. Common sense.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130121/f0d82a9d/attachment.html>

On Mon, Jan 21, 2013 at 3:15 PM, Andrew Trick <atrick at apple.com> wrote:
>
> On Jan 21, 2013, at 3:12 PM, Chandler Carruth <chandlerc at
google.com>
> wrote:
>
> On Mon, Jan 21, 2013 at 2:59 PM, Andrew Trick <atrick at apple.com>
wrote:
>
>>
>> On Jan 21, 2013, at 12:37 PM, Chandler Carruth <chandlerc at
google.com>
>> wrote:
>>
>> 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.
>>
>>
>> Filed llvm.org/pr15025.
>>
>>  - Make a triple an error if there is not support for that target.
>>
>>
>> Filed llvm.org/pr15026.
>>
>>
>> I assume opt should completely ignore target triple when -mtriple is
>> provided,
>>
>
> Yep.
>
>
>>  potentially bypassing the error.
>>
>
> I would expect opt to error on an invalid '-mtriple' just as it
would for
> an invalid triple in the IR....
>
>
> Yes, that's what llc does.
>
> The point is, as long as you specify a valid -mtriple you won't get any
> warning about a bad IR target triple. Common sense.
>
Oh, of course. Yes. =D
>
> -Andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130121/35b15492/attachment.html>