On Thu, Jan 15, 2026 at 09:01:41AM -0700, Jeffrey Law wrote:
>
>
> 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".
Understood. Thanks for clarification.
>
>
> 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?
My knowledge about cse is very thin and so far I don't see how to
implement this in hash_rtx() or tight this with likely-spilled classes.
For example, having
1: r100=%1
2: r101=...
3: r102=exp_a(r100)
4: r103=exp_b(r101)
5: r104=exp_c(r100)
Assume that insn 3 has no hard register constraint, but insn 4 does
which is referring to hard register %1. Then I would still like to keep
track that r100 and %1 hold the same value, while analyzing insn 1,
which enables me to substitute r100 by %1 in insn 3. For insn 4,
however, I would like to invalidate this relation, since operand r101 is
potentially loaded into %1 and would clobber the register. Explicitly
clobbering/invalidating register %1 while analyzing insn 4 ensures that
r100 is not substituted by %1 in insn 5.
Thus, at first encounter I still want to hash a hard register and at
some later point once I encounter a hard register constraint referring to
the same hard register, I want to invalidate it. To be conservative
here, I do this irrespective whether an alternative is likely, unlikely,
or whatsoever. Basically I'm treating a hard register constraint as a
possible load.
In that regard hard register constraints may not be as restrictive as
single register classes, since for the latter even a substitution into
insn 3 wouldn't be done if I read the current implementation correctly.
Cheers,
Stefan
