[LLVMdev] [llvm-commits] [llvm] r172534 - /llvm/trunk/test/Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
chandlerc at google.com
Mon Jan 21 15:12:13 PST 2013
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>
> 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
> 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....
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev