https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #33 from rguenther at suse dot de <rguenther at suse dot de> --- 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? 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. 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.
