On Wed, Jan 18, 2017 at 5:36 PM, Jeff Law <law@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.