On Mon, 6 Jun 2011, Diego Novillo wrote:
> On Mon, Jun 6, 2011 at 10:27, Diego Novillo wrote:
> > On Mon, Jun 6, 2011 at 04:50, Richard Guenther wrote:
> >
> >> I'd have it done in the loop that computes canonical types, at this
> >> place we do not gain the advantage that the decl register func
On Mon, Jun 6, 2011 at 13:02, Diego Novillo wrote:
> On Mon, Jun 6, 2011 at 10:27, Diego Novillo wrote:
>> On Mon, Jun 6, 2011 at 04:50, Richard Guenther wrote:
>>
>>> I'd have it done in the loop that computes canonical types, at this
>>> place we do not gain the advantage that the decl registe
On Mon, Jun 6, 2011 at 10:27, Diego Novillo wrote:
> On Mon, Jun 6, 2011 at 04:50, Richard Guenther wrote:
>
>> I'd have it done in the loop that computes canonical types, at this
>> place we do not gain the advantage that the decl register functions
>> get completely fixed up trees.
>
> Hm, yes,
On Mon, Jun 6, 2011 at 04:50, Richard Guenther wrote:
> I'd have it done in the loop that computes canonical types, at this
> place we do not gain the advantage that the decl register functions
> get completely fixed up trees.
Hm, yes, I had forgotten about the call to rest_of_decl_compilation.
On Fri, 3 Jun 2011, Diego Novillo wrote:
>
> As discussed in http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00063.html,
> this patch moves decl registration in symbol tables to the LTO front
> end. It makes type and symbol registration happen at the same time in
> uniquify_nodes.
>
> Tested with
As discussed in http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00063.html,
this patch moves decl registration in symbol tables to the LTO front
end. It makes type and symbol registration happen at the same time in
uniquify_nodes.
Tested with LTO profiledbootstrap on x86_64. Committed to trunk.
