This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] df: Keep return address register undefined until epilogue_completed
On Mon, Sep 12, 2016 at 10:30:56AM -0600, Jeff Law wrote:
> On 09/10/2016 01:17 AM, Segher Boessenkool wrote:
> >On Fri, Sep 09, 2016 at 04:40:12PM -0600, Jeff Law wrote:
> >>Right now the dataflow is conservatively correct WRT the return register.
> >
> >And conservatively incorrect wrt all other callee-saved regs!
> But prior to prologue/epilogue insertion it shouldn't matter. In fact,
> explicit references to callee saved regs prior to register allocation
> has always been problematical.
>
> I do think our handling of life information for callee-saved regs after
> insertion of the prologue/epilogue could be improved.
And before: it is not really incorrect for a program to access a callee-
saved register (with "register asm", say). Not very useful except for
debugging, but not really incorrect either. This all is handled correctly
for LR already, I'm not sure about LIVE though. Not sure it matters either,
everything seems to stumble along just fine.
> In a separate shrink wrapped world ISTM that we want to move to a model
> where the return insn itself is a use of the appropriate callee saved
> regs. If we did that I suspect some of the hacks from the separate
> shrink wrapping kit would just "go away".
That doesn't help, sorry. In fact the rs6000 port used to do just as you
say (for return patterns; not for simple_return patterns), and that only
hindered optimisation (the exit block already has an artificial use of
the link register, so it is not needed; the return being a parallel was
not recognised by various things).
> Attaching actual USEs to those insns is obviously problematical though
> from a recognition standpoint. It'd probably have to be structured more
> like what we do with CALL_INSNs to mark registers used/set.
And it already is, if I understand you correctly :-)
> >>If we made the change you want to make than the dataflow becomes overly
> >>optimistic about the range over which the return register is live prior
> >>to inserting the prologue/epilogue into the insn chain.
> >>
> >>This seems unsafe to me.
> >
> >Yes, but so does the current situation. And it all seems to work
> >nevertheless :-)
> But that doesn't make it right...
Yes, but neither is the current situation, for powerpc at least: the link
register should *not* be live at function entry, just like the situation
with other callee-save registers, it does not hold a value the current
function has any business with -- before prologue generation.
Now, for separate shrink-wrapping, I want to use the LIVE problem to
determine which basic blocks have which concerns, sorry, need which
components set up; to do that i compute IN+GEN+KILL for the registers
of those components, for each basic block (all this is target code).
This needs those registers *not* marked as live in the entry and exit
blocks, which I probably have to force manually anyway. And the setting
this patch corrects gets in the way for that a bit, and since it is
incorrect in general anyway, I wanted to do something about it.
But I'll just hard force it off during separate shrink-wrapping, and
we'll leave this problem for another day.
Segher