On 1/16/25 1:32 AM, Stefan Schulze Frielinghaus wrote:
Conceptually I see the value in being able to being able to specify a
specific register in an asm. The single register class constraints found on
x86 have effectively given that port that capability, but others which truly
general purpose registers files don't have a good way to do this stuff.
I think we should look to try and move this forward early in the gcc-16
cycle. You're definitely going to need to update the manual for the new
capability.
I added some documentation to gcc/doc/extend.texi. Is there some
other place I should document this?
Not sure how I missed it -- I mostly wanted to walk through the docs
once now to make sure I understood the basic premise of the change as
well as any already identified problem areas.
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'm sure someone will try to implement ABI semantics for asms with calls
at some point on top of this infrastructure. It seems to be a
persistent thing developers want to do with asms. It always ends in a
bit of fireworks either running out of registers in the asm itself or
generating crappy code because of all the hard register usages. Not
something you need to fix, more a rant about what's likely to happen in
the future ;-)
Jeff
