Re: [PATCH] combine: Do not combine moves from hard registers

[Christophe Lyon <christophe.lyon@linaro.org>]

On Tue, 23 Oct 2018 at 14:29, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Tue, Oct 23, 2018 at 12:14:27PM +0200, Christophe Lyon wrote:
> > I have noticed many regressions on arm and aarch64 between 265366 and
> > 265408 (this commit is 265398).
> >
> > I bisected at least one to this commit on aarch64:
> > FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump ira "Split
> > live-range of register"
> > The same test also regresses on arm.
>
> Many targets also fail gcc.dg/ira-shrinkwrap-prep-2.c; these tests fail
> when random things in the RTL change, apparently.
>
> > For a whole picture of all the regressions I noticed during these two
> > commits, have a look at:
> > http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/265408/report-build-info.html
>
> No thanks.  I am not going to click on 111 links and whatever is behind
> those.  Please summarise, like, what was the diff in test_summary, and
> then dig down into individual tests if you want.  Or whatever else works
> both for you and for me.  This doesn't work for me.
>

OK.... this is not very practical for me either. There were 25 commits between
the two validations being compared,
25-28 gcc tests regressed on aarch64, depending on the exact target
177-206 gcc tests regressed on arm*, 7-29 gfortran regressions on arm*
so I could have to run many bisects to make sure every regression is
caused by the same commit.

Since these are all automated builds with everything discarded after
computing the regressions, it's quite time consuming to re-run the
tests manually on my side (probably at least as much as it is for you).

In this case, the most efficient way would be for me to extract your patch
and have my validation system validate it against the preceding commit,
that would give the regressions caused by your patch only. I'm going
to do that, it should take 3-5h to run.

I know this doesn't answer your question, but I thought you could run aarch64
tests easily and that would be more efficient for the project that you
do it directly
without waiting for me to provide hardly little more information.

Maybe this will answer your question better:
List of aarch64-linux-gnu regressions:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/265408/aarch64-none-linux-gnu/diff-gcc-rh60-aarch64-none-linux-gnu-default-default-default.txt
List of arm-none-linux-gnueabihf regressions:
(gcc) http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/265408/arm-none-linux-gnueabihf/diff-gcc-rh60-arm-none-linux-gnueabihf-arm-cortex-a9-neon-fp16.txt
(gfortran) http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/265408/arm-none-linux-gnueabihf/diff-gfortran-rh60-arm-none-linux-gnueabihf-arm-cortex-a9-neon-fp16.txt
(all these are what you get when you click on one of the REGRESSED
links on the main page)

but as I said, these were caused by commits between 265366 and 265408,
so not all of them may be caused by your commit

Don't get me wrong, I'm not angry at you, I don't want to be offending,
I'm very humble.

To me it just highlights again that we need a validation system easier to
work with when we break something on a target we are not familiar with.
I run post-commit validations as finely grained as possible with the CPU
resources I have access to, that's not enough and I think having a
developer-accessible gerrit+jenkins-like system would be very valuable
to test patches before commit. We have a prototype in Linaro, not
production-ready. But I guess that would be worth another
discussion thread :)

Christophe

>
> Segher