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: [lto] PATCH: fill in code to merge declarations


Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> Mark was just trying make something work in the short term. 
>
> Yes, exactly; I thought that, in the short term, you might want to
> just reconstitute the entire body of the function as TREE (ignoring
> the CFG, etc.) and then pass it back through the entire compilation
> stack.  Since I expected re-gimplification to be harmless (as Diego
> confirms), you'd then be able to round-trip code through the LTO front
> end.
>
> I'd expect you to get the same generated code that way that you would
> by reconstituting the CFG and basic-block information, and then
> proceeding from there; the "only" difference would be efficiency,
> since if you re-gimplify and re-build the CFG you presumably get to
> the same state.
>
> I'm not at all discounting the efficiency issue (hence the quotes
> around only above), so it makes sense to me to wire up a way to skip
> these early parts of the middle end.  But, that may require some work.
>
I do not think that this would work without a lot of work.  I believe,
and the gimple elite can correct me, that there are non trivial
transformations in the control flow when the cfg is built and I cannot
just pack it back into a simple linear form. 

I was going to just see what crashes after sandra fixes a couple of
dwarf bugs.  I was thinking that maybe I could teach the cfg building
code to just leave the cfg alone if one is already there. 


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