[llvm-dev] [PATCH] D50328: [X86][SSE] Combine (some) target shuffles with multiple uses

[David Greene via llvm-dev]

[NOTE: Removed Phab and reviewers]

> ================
> Comment at: test/CodeGen/X86/2012-01-12-extract-sv.ll:12
> +; CHECK-NEXT:    vblendps {{.*#+}} xmm1 = xmm1[0],xmm2[1,2,3]
> +; CHECK-NEXT:    vpermilps {{.*#+}} xmm0 = xmm0[0,0,0,0]
>  ; CHECK-NEXT:    vinsertf128 $1, %xmm0, %ymm0, %ymm0
> ----------------
> greened wrote:
>> Can we make this test less brittle by using FileCheck variables?
>> This goes for pretty much every test in this patch.
> I'm sorry but no - its been repeatedly proven that using
> update_llc_test_checks.py on the majority of x86 tests is the way
> forward - it speeds up creation of tests (x86 by far has the highest
> test coverage), makes regeneration of checks trivial and it prevents
> dodgy code being 'hidden' (either on purpose or by
> accident). Additionally many x86 subtargets have different instruction
> behaviours depending on the registers used so hidng the registers
> behind regexps make it that more difficult to track.

Ok, humor me a bit, as I am not at all familiar with
update_llc_test_checks.py.

How is it "proven" that the script is better than writing robust and
focused tests?  IME, updating tests to reflect changed behavior is
problematic.  How do we know the updates reflect "better" compiler
behavior?  Suppose I make a change and a bunch of llc tests fail.  What
do I do?  I have to examine each one to see if the new behavior is
"correct" or not.  Assuming I think it is, I guess I run
update_llc_test_checks.py.  But I didn't write the test so how do I know
the new output is "correct?"

How does the script speed up creation of new tests?

What kinds of dodgy code being hidden are you concerned about?  Can you
provide an example?

If a test is looking for different behavior based on register use, then
of course the test should be written to detect specific register uses.
If the register use changes, the test fails because a bug was
introduced.

I would bet 95% of X86 tests don't care what registers are used
whatsoever.  From my perspective, it would be much better to have 95% of
tests never change over time, leaving a much smaller set of tests that
may never (ideally will not ever) need to be changed, because they are
written to expect specific sequences and violations of those are bugs.

Tests should be focused.  If we're using, for example, a bunch of tests
develped for shuffle selection as proxies for register allocation,
that's not good.  We should have specific register allocation tests.

Is this unreasonable?  Can we not incrementally improve the tests?

                              -David