On 1/14/2026 8:13 AM, Stefan Schulze Frielinghaus wrote:
gcc/ChangeLog:

        * cse.cc (invalidate_from_sets_and_clobbers): Consider any hard
        register referred to by any single register constraint
        potentially being clobbered.

gcc/testsuite/ChangeLog:

        * gcc.target/powerpc/asm-hard-reg-2.c: New test.
Can we really get at the register classes while in CSE?   That's a bit of a
surprise.  My recollection is these kinds of cases a handled by the
likely-spilled hooks.   Look in hash_rtx, where that code is lying around.
ira_class_singleton is setup in
setup_prohibited_and_exclude_class_mode_regs() which is called during
ira_init() which itself is called during backend_init_target().  So my
reading is that it should be save to access during CSE.  On the other
hand I'm wondering why this is not in ira_init_once().  Maybe I'm
overlooking something here.  Let me double check.
Hmm even after giving it a second thought I still don't see a reason not
to access ira_class_singleton since it is set during initialize_rtl().
Maybe I'm overlooking something fundamental here?

Anyhow, I added

         else
           {
             enum reg_class cl
               = reg_class_for_constraint (lookup_constraint (p));
             if (cl == NO_REGS)
               continue;
             machine_mode mode = recog_data.operand_mode[nop];
             int regno = ira_class_singleton[cl][mode];
             if (regno >= 0)
               invalidate_reg (gen_rtx_REG (mode, regno));
           }

for the sake of completeness and symmetry of hard register constraints
and constraints associated a single register class.  Maybe the stage4
interrupt should be applied here, too, i.e., I don't want to risk it and
introduce hiccups.  Would the patch be ok if I remove the else clause
and the include statement of ira.h?
It was more "I didn't realize we could do that" and "we should tie this into the existing mechansisms to avoid CSE in some cases if possible".


The likely-spilled classes machinery can't be used as-is since the decision for your case is dependent upon context (ie, the insn itself and its constraints).  So perhaps what we want is your code to peek at the constraints, but bolted onto the code that's checking for the likely-spilled classes?

Jeff

Reply via email to