https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at gcc dot gnu.org
--- Comment #5 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to sudi from comment #4)
> What I have observed so far is that the failure occurs based on how the
> scheduler (sched1) chooses to schedule the movmem12b instructions (insn 16
> in all the cases below). If that
> instruction is scheduled a bit later (even by one instruction), its all good!
>
> Even though the movmem12b instruction has a very heavy demand on the
> registers, shouldn't the allocator and/or the scheduler be able to detect
> that? Is this a scheduler problem or an allocator problem or neither?
>
It is hard to say which pass (scheduler or RA) is responsible for the bug.
Such bug was frequent for older reload pass. Therefore for i386 the 1st insn
scheduling was switched off long ago.
The newer LRA has a new feature to spill hard reg live range in some cases.
Unfortunately, it does not always work. In this case the scheduler extends
live ranges of hard registers used for parameter passing.
To improve communication of the scheduler and RA. a few years ago a
register-pressure sensitive scheduling was introduced. It should prevent
occurrence of 'unable to find a register to spill' situation and decrease
number of spills in RA.
We have two different algorithms for register-pressure sensitive scheduling.
ARM by default uses the 2nd one (MODEL) probably because it results in a better
generated code. The 1st algorithm (WEIGHTED) is less aggressive but more safe
IMHO. So if you add --param sched-pressure-algorithm=1, the problem goes away.
So I see 3 possible ways to solve the problem:
1. Fix it in RA which would be very hard.
2. Fix it in the 2nd pressure-sensitive insn scheduling. I think Richard
Sandiford would do this as an author of the code or at least to say how hard to
fix the problem there.
3. Use more conservative but safe 1st algorithm. This is the simplest
solution.
I'd like to see other people opinions on what approach to use because I have no
particular preference except avoiding the 1st approach.
