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

[Segher Boessenkool]

Hi Christophe,

On Tue, Oct 23, 2018 at 03:25:55PM +0200, Christophe Lyon wrote:
> 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.

This is PR87708 now.

> > > 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.

So many, ouch!  I didn't realise.

> 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).

Running arm tests is very painful for me.  But you say this is on aarch64
as well, I didn't realise that either; aarch64 should be easy to test,
we have many reasonable aarch64 machines in the cfarm.

> 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.

Well, I'm not too familiar with aarch64, so if you can say "this Z is a
pretty simple test that should do X but now does Y" that would be a huge
help :-)

> 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

That may help yes, thanks!

> 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.

OTOH a patch like this is likely to break many target-specific tests, and
that should not prevent commiting it imnsho.  If it actively breaks things,
then of course it shouldn't go in as-is, or if it breaks bootstrap, etc.

> 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 :)

Yeah...  One when people have time for it ;-)


Segher