This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [df] RFA: artifical defs of global registers for EH, etc.
On Jan 8, 2008 3:25 PM, Richard Sandiford <rsandifo@nildram.co.uk> wrote:
> ""Seongbae Park (박성배, 朴成培)"" <seongbae.park@gmail.com> writes:
> > On Jan 8, 2008 2:44 AM, Richard Sandiford <rsandifo@nildram.co.uk> wrote:
> >> The LR confluence function is:
> >>
> >> /* Call-clobbered registers die across exception and call edges. */
> >> /* ??? Abnormal call edges ignored for the moment, as this gets
> >> confused by sibling call edges, which crashes reg-stack. */
> >> if (e->flags & EDGE_EH)
> >> bitmap_ior_and_compl_into (op1, op2, df_invalidated_by_call);
> >> else
> >> bitmap_ior_into (op1, op2);
> >>
> >> bitmap_ior_into (op1, df->hardware_regs_used);
> >>
> >> But global registers are df_invalidated_by_call, so this means
> >> that there are no reaching definitions for a global register before
> >> the first definition in the exception handler itself.
> >
> > Really? All calls are supposed to have both USE and DEF for global_regs[],
> > so calls themselves should be treated as the definition for global_regs.
>
> Sorry, I quoted the wrong thing. It isn't the LR confluence function
> that matters, it's the reaching definitions function. My point was
> supposed to be that we don't propagate global definitions from the
> source of an EH edge to the destination because all such registers
> are invalidated_by_call.
>
> > The only thing I see missing is global_regs[] missing from entry_block_defs,
> > which we probably should add to.
>
> Yes, that probably is missing too but...
>
> > So, would it be sufficient to add global_regs to entry_block_defs ?
>
> ...it isn't enough on its own.
Now I see what you meant. Because df_rd_confluence_n ()
blows away everything that's df_invalidated_by_call
(through {sparse,dense}_invalidated)
whenever it sees an EH_EDGE,
the first use of a global within the EH region would look
without any reaching def (i.e. uninitialized).
I think your patch is the right approach.
Approved, unless Kenny (or anybody else) finds a regression in his testing.
> Anyway, I'm wondering about doing the MIPS thing a different way,
> so if there's doubt, we might as well drop this patch.
>
> Richard
Seongbae