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:
>
>> 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. 
>
> You may be correct; I'm not sufficiently expert to know either.  It
> might be that to make the plan I suggested work you would need to
> either run an out-of-SSA pass before writing out the trees, or that
> you would have to write the trees out earlier: after they become
> GENERIC, but before they become GIMPLE.  But, it might well also be
> that even these measures would not work.  Even if they do work, it
> might not be a good use of time to do that now, since the plan that
> you're advocating is the one that we really want.
>
The other thing that I can do is add an extra flag to the passes before
lto writing that I turn off at the top lto/lto.c but is otherwise true. 
I have not looked to see if everything is truly a pass, but for the ones
that are this seems like the right thing to do in the short term, maybe
even in the long run. 

I have done this before, so this should be easy for everything that is a
passmanager pass.

>> 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. 
>
> That makes sense to me.  Of course, you'll have to audit for any other
> global variables or data structures that need to be set up --
> hopefully there are not too many...
>
Sandra and I have discussed this privately.  I am just going to end up
with some leaves of trees that have nulls rather than decls or types.  
This will not get too far down the pass stream, but there is a lot that
can be checked here.  As long as you only feed it code that you know how
to generate all the decls and types for this will be fine.  I do local
var and parm decls but these will only have non null types if you can
provide one.  

When you think you are finished, I will change my code so that it
asserts that there are no null leaves.  But for now, it is perfectly
happy to have nothing there.

Kenny




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