https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #34 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #33) > On Sat, 30 Mar 2019, segher at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 > > > > --- Comment #32 from Segher Boessenkool <segher at gcc dot gnu.org> --- > > Historically, a local register asm variable *does* live in that variable > > for its entire scope. This stopped working correctly, even with the many > > caveats there were for it, and many years ago the manual added language > > saying that only using such a var in an extended asm in or out is supported, > > and there was language warning you to keep the life time short, etc. > > > > This did *not* change the implementation. Any other use still is explicitly > > unsupported, and all such testcases are invalid code. > > Hmm, but that means the only effect of a local reg var would be > implicit input/output constraints, right? Explicit. Yes. That is the documented only supported use. But it is not currently the only thing it *does*. > Of course there's also > calls(?) that would need to remat all local register vars. > > The asm part could be easily represented on GIMPLE by making those > constraints explicit. The call issue would need explicit save/restore > code which is then exposed to optimization passes. > > But then... > > > It would be nice if GCC was changed such that such vars were expanded to a > > pseudo like any other var, and copies to/from a hard reg just around the > > asm. > > Gimple doesn't need to do *anything* for that, just keep track that the var > > is declared as local register var, and the gimple it had now at expand is > > just fine: > > ... all this could be done at RTL expansion time as well. Yes, exactly. Gimple could treat local register cars just like any other pseudo. Then at expand time, you copy it into its hard reg right before an asm, and back out after it (maybe skip either if the var is not an input resp. an output of the asm), and everything remat and lifetime etc. will work out automatically. Unless I am missing something. But this is *not* what we currently do, and it is not what is documented, and as far as I can see the testcase here is invalid code. > Still in GIMPLE we'd have to treat calls at modifying/using > local reg vars? That leaves us with forcing of virtual operands > on all calls eventually using those vars. I think it will all work out fine without treating local register var any different from any other local variable.
