[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -mstackrealign -O2 -mbmi -fno-exceptions -fno-plt

["ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Vladimir Makarov from comment #9)
> (In reply to Uroš Bizjak from comment #7)
> >
> > 
> > Please note that the insn is defined as:
> > 
> > (define_insn_and_split "*andn<dwi>3_doubleword_bmi"
> >   [(set (match_operand:<DWI> 0 "register_operand" "=&r,r,r")
> > 	(and:<DWI>
> > 	  (not:<DWI> (match_operand:<DWI> 1 "register_operand" "r,0,r"))
> > 	  (match_operand:<DWI> 2 "nonimmediate_operand" "ro,ro,0")))
> >    (clobber (reg:CC FLAGS_REG))]
> > 
> > where the problematic alternative (=&r,r,ro) allows a memory input in its
> > operand 2 constraint. The allocator could spill a DImode value to a stack in
> > advance and reload the value from the memory in this particular alternative.
> 
> That is not how LRA (and the old reload) works.  If an operand matches the
> constraint (r in ro), it does not change its location (do reloads).
> 
> In general, it is possible to implement reloads for operands already matched
> to a constraint but this would significantly complicate already too
> complicated code.  And probably heuristics based on reload costs would
> reject such reloads anyway.
> 
> I probably could implement reg starvation recognition in process_alt_operand
> and penalize the alternative and most probably it will not affect other
> targets.  Still it is not easy because of different possible class subsets
> or intersections.
> 
> Still I think Jakub's solution is reasonable at this stage.  If I implement
> my proposed solution we could commit it after the release.

Yes, I agree. Not knowing the internals of the RA, it looked "obvious" that RA
could use memory operand here, and using this solution in the
target-independent code could solve the issue also for other register starved
targets.

Another long-term improvement in the RA could be allocating multi-regs in a
random order. As far as x86 is concerned, apart from passing function
parameters in registers and perhaps some asm constraint ("A"), there is no need
for double-word registers to be allocated in any specific order. The
double-word value could be allocated in {hi,lo} register tuplet, where hi and
lo can be any register. Using this approach, the RA could allocate a
double-word value also in [01]2[34]5 situation.