[llvm-dev] Loop Vectorize: Testing cost model driven transformations

[Renato Golin via llvm-dev]

On 30 November 2016 at 19:53, Michael Kuperstein via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Yeah, this makes a lot of sense, -mcpu=generic (as opposed to -mcpu=native)
> is the sane default.
> I guess I was just expecting an x86 host to get a "generic x86 TTI"
> (whatever that means), not a "generic TTI".

I think using "generic" is the way to go here, but it's still *not*
target-independent.

-march=x86 -mcpu=generic -> i586? (SSE?)
-march=x86_64 -mcpu=generic -> Pentium what? (SSE? AVX?)
-march=arm -mcpu=generic -> ARM7TDMI (ARMv4T, no VFP, no NEON)
-march=aarch64 -mcpu=generic -> Cortex-A53 (ARMv8, VFP + SIMD)

So, if you don't specify -march, but use -mcpu=generic, when you run
the tests on native ARM/AArch64, you'll get different results on your
target-independent tests if they can support vector code at all.

We currently build *only* the ARM back-ends on the ARM native bots
because building x86 takes a long time and that's being tested
elsewhere. That's why we get a lot of test failing when they expect
the x86 back-end to exist (via -march=x86_64).

My point is, there is no safe way to do target-independent tests of
the vectorizer if you don't force "some" parameters.

However, it should be mostly fine, as we don't really need all bots to
test all things. If the x86_64 bots are testing the generic IR
transformations and the ARM bots are testing the ARM specific ones,
we're mostly covered.

We may let slip a thing or two in the cost models, but other tests
(like self-hosting, test-suite, benchmarks) will eventually pick them
up. In this case, we should add a new target-specific test on the ARM
side to make sure we don't regress again.

Does that make sense?

cheers,
--renato