[lto][patch] Don't write DECL_CONTEXT of LABEL_DECLs
Sat Jan 24 17:13:00 GMT 2009
> DECL_CONTEXT for a label *is* used. You stated in the next comment
> that cfgexpand makes use of it. We run cfgexpand both in cc1/cc1plus
> and lto1. So, if it's used in cc1/cc1plus, it *is* used in lto1
Why do we run cfgexpand in lto1?
>> While streaming out label_decls, we might see
>> a DECL_CONTEXT that is not NULL. So the comment explains that there is
>> a know disparity from what existed on cc1 and what we are constructing
>> on lto1.
> Sure. But that's not all that the comment says. The comment says
> that the context of labels is no longer used. That's what doesn't
> seem right to me, based on your other comment.
>> This value will not be overwritten while reading the
> What about this?
> else if (code == GIMPLE_LABEL)
> DECL_CONTEXT (gimple_label_label (stmt)) = fn->decl;
It sets the value of the LABEL_DECL we get while reading a
GIMPLE_LABEL. But again, we read the label twice. In one instance the
DECL_CONTEXT is set. In the other it isn't.
Let me explain this better:
if in a function we have
static void *p = &&a;
the label "a" will be written twice. Once it will be written while
writing a function. On reading it back in, the DECL_CONTEXT is set
correctly. The other time it is written is while writing the initial
value of "p". That is the case this patch changes.
In lto1 thee label "a" now has two representations. One came from
reading the GIMPLE_LABEL and one came from reading the initial valu of
"p". The DECL_CONTEXT of the second instance is the one that is not
used. As the FIXME notes, it would be better to change this to have
only one copy of the label, but that is hard. I tried, have to change
the streamer quiet a bit.
Rafael Avila de Espindola
Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047
More information about the Gcc-patches