On 04/28/2015 08:36 AM, Alan Lawrence wrote:
Ah, yes, I'd not realized this was connected to the jump-threading
issue, but I see that now. As you say, the best heuristics are unclear,
and I'm not keen on trying *too hard* to predict what later phases
will/won't do or do/don't want...maybe if there are simple heuristics
that work, but I would aim more at making later phases work with
what(ever) they might get???
Yea, in various places we do try and "predict" what form will be best
for later passes, but it's rarely
the best way to do things.
One (horrible) possibility that I will just throw out (and then duck),
is to do something akin to tree-if-conversion's
"gimple_build_call_internal (IFN_LOOP_VECTORIZED, " ...
It's not as terrible as you might think. The ability to present two
forms to the vectorizer has a variety of uses.
The one thought we've never explored was re-rolling that first
iteration back into the loop in the vectorizer.
Yeah, there is that ;).
So besides trying to partially-peel the next N iterations, the other
approach - that strikes me as sanest - is to finish (fully-)peeling off
the first iteration, and then to vectorize from then on.
WHich is better may depend on a variety of factors. Complexity of the
loop, the iteration space, etc. etc. I suspect it's not terrible to
unpeel -- there's two parts. One recognizing particular patterns in the
CFG that come from the partial peeling, then detecting that two blocks
are still essentially the same, except for the control flow bits at the
end of the block.
whereas with rerolling ;)...is there perhaps some reasonable way to keep
markers around to make the rerolling approach more feasible???
I suspect (but certainly haven't really investigated) that the CFG will
have tell-tale signs and that we then look at the key blocks.
Jeff
