On Wed, Jan 18, 2017 at 5:36 PM, Jeff Law <l...@redhat.com> 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.
I think that walks in the wrong direction and just distributes the hack over multiple files. I'd rather have it in one place. Richard. > jeff >
