https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #9 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- (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.
