Fix PR44281 (bad RA with global regs)

[Michael Matz]

Hi,

On Fri, 26 Feb 2016, Bernd Schmidt wrote:

> Calls do, asms currently don't AFAICT. Not sure whether it's allowed to 
> use them, but I think it should be straightforward to adjust df-scan.
> 
> > Some jit-like code uses global reg vars to reserve registers for the 
> > generated code.  It would have to add -ffixed-<name> compilation 
> > options instead of only the global vars after the patch.  I think the 
> > advantages of having "good RA" with global reg vars are dubious enough 
> > to not warrant breaking backward compatibility.
> 
> I don't see the need for new options - if we have proper live info for 
> calls and asms, what other reason could there be for incomplete liveness 
> information?

[now moot, since wontfix, but still:]

Well, but we don't have proper live info, as you already said yourself 
above.  What I mean to say is, the following is currently proper use of 
global reg vars:

----
register uint64_t ugh __asm__("rbx"); //r11, whatever
void write_into_ugh (void)
{
  asm volatile ("mov 1, %%rbx" :::);
  assert (ugh == 1);
}
----

%rbx would have to be implicitly used/clobbered by the asm.  In addition 
it would have to be used by all function entries and exits (so that a 
function body where the global reg var is merely visible but not used 
doesn't accidentally clobber that register) and of course by calls.

AFAICS this would fix the code in push_flag_into_global_reg_var, because 
then indeed you'd have proper live info, including proper deaths.  But for 
everything a little more complicated than this it'd basically be the same 
as putting the reg into fixed_regs[].

FWIW: signal handlers need no consideration (if they were allowed to 
inspect/alter global reg vars we would have lost and no improvement on 
fixed_regs[] could be done).  They are explicitely documented to not be 
able to access global reg vars.  (They already can't accidentally clobber 
the register in question because signal handlers don't do that)

So, I think it can be made to work, but not something for GCC 6, and if 
the additional bit for all calls/asms/function-entry-exits really is worth 
it ... I just don't know.


Ciao,
Michael.