Re: [RFC] LRA: Carrying hard registers around

On 6/24/26 3:04 AM, Stefan Schulze Frielinghaus wrote:
> Hi all,
>
> Live range splitting for hard regs which are assigned to some pseudo is
> already implemented.  However, live ranges of hard regs which are live
> due to hard register assignments are not split so far which may result
> in unsatisfiable allocations.


As I understand, there was a consensus that we should avoid to use hard 
regs wherever it is possible.  It is better to create new moves 
involving hard regs and pseudos and use pseudos instead of the hard reg 
wherever it is possible.  RA will usually assign the pseudo to the hard 
reg when it is possible effectively removing such moves.

It simplifies work of RA and makes it more stable.  It also simplifies 
and improves optimizations before RA.

Hard reg life should be minimal (e.g. from assigning to arg reg to the 
call) or only in places of usage of local register variable or in 
asm. And optimizations should not make life longer.  For example, Segher 
Boessenkool worked on preventing hard reg propagation in combiner.  Life 
of arg regs was also implemented to be shorter in the function prologues.

That said, unfortunately there is still code where hard reg usage is not 
minimized, especially code originating from machine-dependent parts. And 
it was a problem especially for targets (e.g. x86) with insns requiring 
specific regs.  It was a problem for the reload pass and early LRA.  
Compilation failed with message about impossibility to find hard reg for 
a reload pseudo.

But hard reg life split was implemented in LRA long ago (see 
lra-constraints.cc:split_if_necessary).  First splitting for pseudos was 
implemented and on its base splitting of hard reg was implemented too.  
Maybe the implementation does not fully and optimally solve the problem 
but I did not see PRs about this for a long time.

Sorry, I don't think the proposed work is necessary.  Even if we could 
implement splitting more optimally, as I wrote, we should focus on 
minimizing hard reg life instead.



>    For example, assume that
> FIRST_PSEUDO_REGISTER == 100
>
> 1: r5=...
> 2: r101=exp(r100)
> ...
> 9: // some user of r5
>
> Furthermore, assume that in insn 2 the input operand is constrained to
> hard register r5 (e.g. via a hard register constraint, a single register
> constraint as e.g. {a,b,c,d,S,D} from x86_64, or even via a new
> dependent register filter assuming there was another input operand
> resulting in r100 being constrained to r5).
>
> In those cases we need to temporarily free hard register r5 for insn 2.
> I have been playing with an implementation where we end up with:
>
> 1: r5=...
> 3: r102=r5             // free r5
> 4: r103=r100           // assign r5 to input reload r103
> 2: r104=exp(r103)
> 6: r101=r104
> 5: r5=r102             // restore r5
> ...
> 9: // some user of r5
>
> The implementation is naive in the sense that it is not checked for an
> optimal restore point for r5, i.e., insns 3 and 5 are always emitted;
> independent of subsequent insns and whether they run into the same
> problem w.r.t. r5 which could in the worst case lead to many unnecessary
> "in-between" reloads.
>
> However, before diving into those missed optimizations, I would rather
> like to fix the place where such reloads should be introduced.  At the
> moment I decided to check during curr_insn_transform() whether the
> currently selected alternative makes use of a hard register constraint
> and whether this particular hard register is live.  If so, then create a
> new reload and emit moves before/after.  The obvious problem with this
> is, there is no liveness information at this point in time.  We could
> compute liveness just prior constraint handling (that's what I'm doing
> in my hack), however, from the liveness information we cannot
> distinguish why a hard register is live, i.e., whether it is live
> because we assigned it to a pseudo or whether it is live due to a hard
> register assignment as e.g. given in insn 1 above.  In the former case I
> think it would be better to rely on the current split mechanism for
> pseudos.
>
> Of course, we might unnecessarily introduce save/restores, if
> implemented via curr_insn_transfrom(), in case a single alternative
> contains not only a hard register constraint but also another constraint
> which is chosen in the end which in turn may result in r5 not being used
> rendering the save/restore unnecessary.  This would be another missed
> optimization.  Again, for the moment, I'm focusing on getting rid of
> ICEs.  Speaking of ICEs my current implementation hack also does not
> differentiate between spilling to registers vs. memory which may lead to
> other ICEs in the end in case of high register pressure.  I haven't
> looked into that so far.
>
> Before making any substantial changes: any thoughts about this?  Maybe
> there is a better place or mechanism to handle this at all?  I'm not
> expecting that we often hit those cases for most targets.  Especially,
> since on x86_64 with single register constraints I'm not aware of a real
> world example which fails due to this problem (even though some of them
> may have been obscured over the years by subsequent fixes in numerous
> passes).  That being said, for a first implementation, I would rather
> aim for a computational inexpensive solution instead of trying to emit
> optimal code in each and every scenario which is why I started by simply
> carrying hard registers around a single instructions.  Maybe some sort
> of light-liveness which considers only hard register assignments, which
> isn't influenced by pseudo allocation and is therefore to some degree
> static, would be enough.
>
As I know there was a consensus that we should avoid to use hard regs 
where it is possible.  Hard reg life should be minimal (e.g. from 
assigning to arg reg to the call).  And optimizations should not make 
life longer.  For example, Segher Boessenkool worked on preventing hard 
reg propagation in combiner.