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

[Richard Guenther <richard dot guenther at gmail dot com>]

On Tue, Apr 27, 2010 at 1:48 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> 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?

Just claim an unused bit from tree_decl_with_vis, like
in_constant_pool (similar to in_text_section).

Thanks,
Richard.

> --
> Eric Botcazou
>