Generally, nobody is really happy with it :) It has been limping along
for a while and not been used a lot at all.
I also see it does compute post-dominators and scrap them for each
costing done! For larger functions with many loops that's going
to be slooooow (it's O(function-size)). I think of SPEC WRF here.
Yeah, we tested with both wrfs back when the heuristic was first installed.
It didn't seem that bad. There are also other unfortunate algorithmic
decisions still...
It's used only in max_number_of_live_regs which does
/* Collect user explicit RVV type. */
auto_vec<basic_block> all_preds
= get_all_dominated_blocks (CDI_POST_DOMINATORS, bb);
tree t;
FOR_EACH_SSA_NAME (i, t, cfun)
{
WTF does this do? We are processing a single loop [nest], we
are in LC SSA, why do we care for any SSA uses outside of
the loop body!? It _does_ all look like a property that
can be incrementally updated during the add_stmt hook calls?
I do wonder if anybody reviews this stuff to make sense :/
We (mostly I) made a judgement call back then whether to go ahead with
it or not despite the numerous issues and wanted to re-evaluate after a while
whether it's useful or not. At the time It seemed like a few people
cared a lot about this particular feature and the expectation was that
maintenance as well as improvement would continue over time. It clearly
hasn't and we haven't re-evaluated. Also, interest has largely faded.
I always wanted to rework large parts but it has been so low on my todo list
that I never got to it. And yes, incremental updating was in that plan.
I wonder if it's easier to remove the whole heuristic for now and re-introduce
at a later time rather than playing catch-up with vectorizer changes starting
from a broken base (and blocking progress).
--
Regards
Robin
