On 1/26/25 12:24 PM, Jakub Jelinek wrote:
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?
Unclear at this point, though leaning towards not strictly requiring a
change to that code, though we may be able to clean it up as a result of
Stefan's work.
Essentially he's code code to split ranges, which in theory we could use
to split ranges of pseudos in likely spilled classes and perhaps
simplify or improve that code.
Jeff
