On Sun, Jan 26, 2025 at 08:35:29AM -0700, Jeff Law wrote:
> On 1/23/25 8:49 AM, Stefan Schulze Frielinghaus wrote:
> > On Sat, Jan 18, 2025 at 09:36:14AM -0700, Jeff Law wrote:
> > [...]
> > > > > Do we detect conflicts between a hard register constraint and another
> > > > > constraint which requires a singleton class? That's going to be an
> > > > > error I
> > > > > suspect, but curious if it's handled.
> > > >
> > > > That is a good point. Currently I suspect no. I will have a look.
> > > Thanks. It's not the most important thing on our plate, but given the way
> > > x86 is structured we probably need to do something sensible here.
> > >
> > > I also worry a bit about non-singleton classes that the target may have
> > > added to CLASS_LIKELY_SPILLED_P, though unlike the singleton case, there's
> > > at least a chance these will work, albeit potentially generating poor code
> > > when an object needs spilling. I also don't think it's terribly common to
> > > add non-singleton classes to that set.
> >
> > I was first worried that the single register class construct is somewhat
> > special. To me, it turns out that they behave very similar to my
> > current draft. Basically during LRA in process_alt_operands() I'm
> > installing
> Yea, I would think they'd largely behave like your proposal. Given the
> presence of a singleton class one could use that to write an ASM just as
> effectively as your hard register proposal. And satisfying the constraints
> should boil down to the same basic process.
>
> What your proposal does is give users fine grained control as-if the port
> had a singleton class for every register -- without us having to add all
> those pesky register classes.
Though, don't we have various hacks for small register classes?
I mean e.g. targetm.class_likely_spilled_p calls in
combine/cse/loop-invariant etc.
If all the registers could be made to behave similarly, don't we need to
create those similarly?
Jakub
