Re: [lto] PATCH: fill in code to merge declarations

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Diego Novillo wrote:
> Kenneth Zadeck wrote on 09/15/06 19:52:
>
>   
>> only correctness.  I am new to this and do know really know how
>> different all of the dialects interact.  If it will pass thru unchanged,
>> then it is certainly ok for now.  However, I have things like basic
>> blocks and the cfg, not a single list of statements and exception
>> regions already built, so if the gimplifier is going to get stuck on
>> these we will need to work on this.
>>
>>     
> Depending on how you invoke it, the gimplifier will probably not get to
> see all the code.  If your code is already split into basic blocks, it
> means that you no longer have a single stream of instructions.  You have
> discrete chunks of IL associated with the various basic blocks.
>
>   
This is exactly what I was asking about.  I have the gimple code in
basic blocks. 

> So, if you call gimplify_function_tree, DECL_SAVED_TREE will be NULL,
> and it will do exactly nothing.  You'd have to traverse the CFG and
> gimplify each block.  But if you already have the CFG, then the code in
> each BB should already be GIMPLE.  Or are you adding new arbitrary code?
>
>   
Mark was just trying make something work in the short term.  The front
ends call the gimplifier and the rest of the compilation stack.  LTO is
a front end and he was hoping he could get away in the short term
without having to build a special pathway that avoided anything.

It may not be to our advantage that the gimplifier does not see the
code.  Because it was not going to add any value anyway.

What might need to be hacked in the short term is some mechanism to keep
the cfg builder from wiping out my cfg with my code already in it.

> I'm assuming that you mean in-memory CFG.  I don't really know how you
> are laying out the CFG on disk.
>
> Gimplifying a GIMPLE instruction is only inefficient.  It should not be
> incorrect.
>