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.
