This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Uniquization of constants at the Tree level


> I'm worried about the section trick - when reading back in the LTO
> IL we'll fail to recognize it because tree_constant_section_name
> is not restored (or merged) and thus the simple equality check
> in DECL_TREE_LEVEL_CONSTANT_P will fail.

Yes, the VAR_DECL will still be shared but not recognized as coming from the 
uniquization machinery.  This is a pessimization if the same constant is 
emitted later during RTL expansion, but the code should be correct (the LTO 
test you suggested runs correctly with the unmodified patch).

> Using a CONST_DECL may be a trick to avoid this?  If you think that's
> not going to work then maybe claiming a tree flag would?

I don't see how using a CONST_DECL could avoid this.  Moreover, the RTL symbol 
generated by the uniquization machinery needs to be attached somewhere if we 
don't want to recompute it every time the constant is referenced, and generic 
CONST_DECLs don't have RTL symbol.

A tree flag will do the job.  The RTL symbol will be recomputed on the first 
call to SET_DECL_RTL and attached to the restored VAR_DECL.  The side effect 
of the operation is that a second VAR_DECL will be created; however, since it 
won't be referenced at the tree level at all, varpool should discard it in 
the end.  And, if the same constant is emitted later during RTL expansion, 
the RTL symbol will be correctly reused.  Inter-unit uniquization should work 
as well.  I'll write tests to exercise the various cases.

Do you have a preference for the tree flag?

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]