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] remove rebuild_ssa_for_lto


On 12/4/07, Nathan Froyd <froydnj@codesourcery.com> wrote:
> On Mon, Dec 03, 2007 at 08:19:03PM -0500, Daniel Berlin wrote:
> > On 12/3/07, Nathan Froyd <froydnj@codesourcery.com> wrote:
> > > This patch forges ahead with the plan I suggested Friday to remove the
> > > current full rebuilding of SSA we do.
> ...stuff...
> > This is, well, not right.
> > 1. You should be running pass_referenced_vars, which will find all the
> > referenced vars for you and add them. If it doesn't, it is buggy, and
> > should be fixed.
>
> It works fine; it worked prior to this.  The checking for MTAGs is also
> bogus; that remained in there from when I was playing with stuff
> earlier.

>  But what is the advantage to letting pass_referenced_vars do
> this work rather than calling add_referenced_var where appropriate
> beyond division of labor?

Well, in this case, we are going to end up calling
pass_referenced_vars *anyway* since it is in the pass pipeline.

I spoke with kenny about this, and the main poin is that either you
should get rid of pass_referenced_vars (by adding the same type of
code in another place in the compiler that is not in the LTO path), or
you should use it.
I have no care in the world which you choose.  But duplicating it's
work when it's going to be run anyway is just asking for maintenance
hassles.

>
> > > +      /* Fill in properties we know hold for the rebuilt CFG.  */
> > > +      cfun->curr_properties = PROP_ssa | PROP_alias;
> >
> > You can't have PROP_alias unless you have rebuild NMT's, SMT's, mtags,
> > partitioning info, addresses_taken, call_clobbering, SFT's, etc.
> >
> > The passes LTO calls when it is done reading in should include
> > pass_referenced_vars and have a TODO_may_alias on one of them (The
> > first that normally does this is pass_create_structure_vars).
>
> OK, so this bit is bogus too.  Removing PROP_alias here doesn't hurt
> anything.  But why do we need to have TODO_may_alias immediately after
> reading?

You don't, as long as you use the normal pass pipeline when you are done reading


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