On Thu, Sep 3, 2026 at 2:33 PM Robin Dapp <[email protected]> wrote:
>
> > How often does this work in practice? That is, where do we get those
> > ranges from? When I thought about re-associating signed expressions
> > I've always thought we'll have to rewrite to unsigned arithmetic and the
> > important thing is to avoid that when the expressions do not simplify.
>
> Yeah, not too often :) (I presume even non-global ranges wouldn't change
> a lot, but haven't measured). I guess the most common case is
> promotions (like int foo (char *a, char *b) {return a + b;}). But it
> works for my motivating example at least (reassoc-58.c).
>
> This patch was done mostly independently and before the others.
> Initially, I just wanted to carve out a subset of signed sequences that
> reassoc (except undistribute) can safely run for, thus any association.
> The idea was that we could extend the set incrementally but I'm starting
> to doubt that way as we'll need to integrate unsigned rewriting more
> tightly.
>
> So, likely this patch isn't really a stepping stone towards the full
> solution. If you don't consider it useful enough in itself, I don't
> think it makes too much sense pursuing it (apart from the motivating
> example of course, but...)
Yeah, I think it doesn't belong into this series at least. I have also
(multiple times now ...), done the flag_wrapv = 1; before the last reassoc
pass idea. -fwrapv is what we have on RTL so it made some sense to
try transitioning to that earlier. But "late" reassoc is quite early, so it
regresses things a lot, and we now use ranger during RTL expansion
even. Also it catches the actual expression simplifications only late.
> > Also you seem to require the whole expression to have no possible
> > overflow (in any association). But if you'd integrate the check into
> > the linearization step itself you could stop expanding problematic
> > leafs instead? The key observation is that (a + b) might have
> > a smaller range than a and b individually (also not sure how often
> > this happens in practice).
>
> The plus/mult stuff came later and I haven't thought of integrating the
> check (also because this patch here was done somewhat independently and
> before the others). Might be worth a try, though.
>
> > That said, I think a tree_overflow_p check would be more useful
> > at the rewriting stage to assess whether we need to pun to
> > an unsigned type and also possibly to find an optimal association
> > that allows to keep signed arithmetic?
>
> I haven't yet wrapped my head around how to get to an optimal tradeoff
> here, let's see.
One motivating thing would be to get rid of the fold-const.cc:fold_binary
code doing
associate:
/* In most languages, can't associate operations on floats through
parentheses. Rather than remember where the parentheses were, we
don't associate floats at all, unless the user has specified
-fassociative-math.
And, we need to make sure type is not saturating. */
...
which is using split_tree () and associate_trees () (and in foldish ways
does this effectively recursive).
Richard.
>
> --
> Regards
> Robin
>
