Hello,
On Wed, 24 Jun 2026, Stefan Schulze Frielinghaus wrote:
> > That's the problem then. Register vars should expand to pseudos, and
> > as you can see in this thread I was pretty sure that its done that way
> > after all the years and something just broke that. Also see the bug
> > Alexander referenced, where also Segher agreed. Consider me baffled
> > and surprised that not more breaks left and right :-)
> >
> > So, I don't want to distract you much further, and will get back to
> > under my stone, but I think instead of trying to rectify this
> > brokenness it would be better in the grander scheme of things if
> > register vars were just finally expanded as pseudos, with copy-in/out
> > around inline asms. (perhaps even copy-in/out around statements that
> > aren't inline asms but refer to the variable, just so to keep historic
> > broken uses like "register long stackp asm("sp"); return stackp;"
> > working :-) )
>
> Well, again, this is not only about register asm. Also targets may emit
> hard register assignments directly which I'm afraid may lead to such
> cases as long as not every optimization pass skips those.
It can emit assignment to hardregs fine. What is suspect is the
expectation that such hardreg then will contain that set value at a later
point. That was always wonky, nothing new here. (And I can't imagine
targets having gotten away with such for an extended time)
> In a perfect world prior RA, no hard registers would occur in RTL.
> Once we are there, we don't need this anymore. Until register asm and
> not each and every target doesn't make use of hard register assignments
> prior RA anymore, we somehow need to deal with this. Some targets are
> affected less, some more.
That we didn't need to deal with this the last 40 years should be a hint
that it can't be new infrastructure that is missing.
Ciao,
Michael.
