Re: [PATCH] diagnose unsupported uses of hardware register variables (PR 88000)

[Segher Boessenkool <segher at kernel dot crashing dot org>]

On Wed, Nov 14, 2018 at 12:40:01PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 14, 2018 at 05:35:06AM -0600, Segher Boessenkool wrote:
> > On Wed, Nov 14, 2018 at 10:47:57AM +0100, Jakub Jelinek wrote:
> > > This makes no sense to me.  There is nothing unsupported in passing
> > > a local hard register variable to a function, that is well defined,
> > > and as your testcase changes show, you broke quite some completely valid
> > > testcases with that.
> > 
> > What could perhaps be useful is a warning for a local register var that
> > is not used in any asm?
> > 
> > > What doesn't work as the reporter expect is assumption that local hard
> > > register variables that live across function calls must have their values
> > > preserved; they can be modified by the callees.
> > 
> > It would be really nice if we could fix that :-)
> 
> You mean for all local hard register variables living across function calls
> save them into temporary and restore them around the calls?
> One issue is that those variables aren't in SSA form, so liveness analysis
> is harder.  And, would we want to have an exception for the stack pointer?
> I mean there is no need for register void *sp __asm ("rsp"); to be
> saved/restored that way, it shouldn't change value across function calls.
> Plus, as has been mentioned, function calls aren't the only issue here,
> e.g. division/modulo etc. that require specific hard registers might clobber
> them too.

I was thinking put them in pseudos always, just copy them to the hard reg
right before the asm statements that use them (and the other way around,
for outputs).


Segher