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
