On Wed, 23 Jul 2025, Robin Dapp wrote:
> 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.
Well, that's how it always goes ;)
> 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).
That was my immediate impulse, but ...
Richard.
