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

[Bruce Hoult via llvm-dev]

On Wed, Aug 8, 2018 at 9:08 AM, David Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Simon Pilgrim <llvm-dev at redking.me.uk> writes:
>
> > Changing a test's IR to avoid an issue in a patch is very problematic,
> > but if any test's codegen changes because of a patch then it just
> > needs to be reviewed, preferably by someone who has touched that test
> > in the past.
>
> But wouldn't it be even better if that output didn't need to be changed
> at all and therefore didn't need to be reviewed?  Right now a lot of X86
> changes have a lot of noise in the diff due to test output (asm)
> changes.  A fair majority of those changes are incidental to a given
> patch.
>

I'm working on the RISC-V port and I find the tests extremely brittle and
what should be independent tests getting "broken" (not really broken, just
codegen changed a little) all the time.

Some examples I've come across recently:

- 128x128 multiply on rv32. Generates several dozen inline instructions.
Any change in which temporary register the compiler picks for any single
instruction breaks it. Any instruction scheduling change breaks it. An
operational test checking the results of some random values and some
extreme values on qemu would be much better I think. All the major llvm
target ISAs are supported in qemu, and I suppose the rest have some other
emulator.

- several months ago the code generator started using an alias "ret"
instead of "jalr x0,x1,0" (jump to the address in register x1 (+0 offset)
and store the old PC in register x0 i.e. discard it). That broke literally
every test. Other recent changes such as outputting "mv a,b" instead of
"addi a,b,0" broke tests all over the place, though of course fewer of them.

- another patch (not yet merged to master) outputs stack use metadata just
after the addi that adjust the stack pointer at the start of a function.
It's not even actual code, but it breaks every test that makes a stack
frame (thankfully most tests are too simple to need one).

Yes, there are scripts to automatically regenerate tests. Hopefully after
making sure that the changes to the output are not in fact bugs :-) It
seems pretty cumbersome to use the output from llvm-lit to track down what
it's actually complaining about. I'm gravitating to just running the update
script for all tests and then using git diff to see what it changed. And,
as mentioned, the diffs in the tests are often orders of magnitude bigger
than the diffs for the actual code.

Is this the same for all ISAs? Is it really the best way? Maybe it calms
down once a back-end is more mature.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180808/429e7e01/attachment.html>