> 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...)
> 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.
--
Regards
Robin
