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: [PATCH 9e] Update "startwith" logic for pass-skipping to handle __RTL functions


On Wed, 2017-01-18 at 09:36 -0700, Jeff Law wrote:
> On 01/17/2017 02:28 AM, Richard Biener wrote:
> > > 
> > > This feels somewhat different, but still a hack.
> > > 
> > > I don't have strong suggestions on how to approach this, but what
> > > we've got
> > > here feels like a hack and one prone to bitrot.
> > 
> > All the above needs a bit of cleanup in the way we use (or not use)
> > PROP_xxx.
> > For example right now you can't startwith a __GIMPLE with a pass
> > inside the
> > loop pipeline because those passes expect loops to be initialized
> > and be in
> > loop-closed SSA.  And with the hack above for the property
> > providers you'll
> > always run pass_crited (that's a bad user of a PROP_).
> > 
> > Ideally we'd figure out required properties from the startwith pass
> > (but there's not
> > an easy way to compute it w/o actually "executing" the passes) and
> > then enable
> > enough passes on the way to it providing those properties.
> > 
> > Or finally restructure things in a way that the pass manager
> > automatically runs
> > property provider passes before passes requiring properties that
> > are
> > not yet available...
> > 
> > Instead of those pass->name comparisions we could invent a new flag
> > in the
> > pass structure whether a pass should always be run for __GIMPLE or
> > ___RTL
> > but that's a bit noisy right now.
> > 
> > So I'm fine with the (localized) "hacks" for the moment.
> David suggested that we could have a method in the pass manager that 
> would be run if the pass is skipped.  "run_if_skipped" or some such.
> 
> What I like about that idea is the hack and the real code end up in
> the 
> same place.  So someone working on (for example) reload has a much 
> better chance of catching that they need to update the run_if_skipped
> method as they make changes to reload.  It doesn't fix all the
> problems 
> in this space, but I think it's cleaner than bundling the hacks into
> the 
> pass manager itself.
> 
> Would that work for you?  It does for me.
> 
> jeff

FWIW I posted an implementation of the idea here:
  https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01268.html


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