On Wed, Jun 24, 2026 at 07:31:44PM +0200, Michael Matz wrote:
> Hello,
>
> On Wed, 24 Jun 2026, Stefan Schulze Frielinghaus wrote:
>
> > > > Due to register asm, hard register r18 is live across the division.
> > >
> > > And that's the bogosity. The register variable r18 can live in a
> > > pseudo during that division, and _should_ live in a pseudo outside of
> > > the specific setup/teardown sequences of the two inline asms.
> >
> > This is not how register asm is implemented in GCC. During expand
> > assignments involving register asm reduce to simple hard register
> > assignments (that is the whole point why I came up with [1] which is
> > supposed to fix at least this). There are no pseudos involved.
>
> 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. 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.
Cheers,
Stefan
