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

Moving to llvmdev...

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

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

+1

--renato

Filed llvm.org/pr15025.

Filed llvm.org/pr15026.

I assume opt should completely ignore target triple when -mtriple is provided, potentially bypassing the error.

-Andy

Moving to llvmdev...

> 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

Moving to llvmdev...

> 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

Hi Andy,

Thank you for creating the two PRs.

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.

This would certainly require some effort as there are about a few hundred test-cases to validate for their target independence.

Regards,

Manish