Re: [PATCH] Ignore (possible) signed zeros in operands of FP comparisons.

[Andrew MacLeod <amacleod@redhat.com>]

On 3/18/22 03:43, Roger Sayle wrote:
> Hi Jeff/Andrew,
>> If you're going to do more work in this space, you might want to reach out to
>> Aldy and Andrew to see if there's space for collaboration.
> One (clever?) suggestion that I do have for ranger would be to add support for
> an additional value_range_kind, VR_NONZEROBITS, which would be a variant of
> VR_RANGE (for unsigned types?) and require very few changes to the existing


I think were ahead of you here.. Tracking known zero and one bits within 
irange as an adjunct has been in plan for awhile, just priorities 
haven't allowed us to get to it until recently...

Theres a bunch of stuff already in the hopper for the next stage1 that 
Aldy has been working with... he can expound upon it, but we plan to use 
both masks and ranges together  as appropriate.


> code.  Just like VR_RANGE all values would lie in [MIN, MAX], so by default
> treating this value_range_kind identically to VR_RANGE there should be no
> visible changes, but the change in semantics is that MIN has the minimum bits
> set, and MAX, the maximum bits set [equivalent to the RVAL and RMASK pairs
> from CCP's bit_value_{bin,un}op].  Hence, the VR_NONZEROBITS range [2,7]
> would represent the possible values {2, 3, 6, 7} rather than {2, 3, 4, 5, 6, 7}.
> For a small number of bits, int_range can already handle this with multiple
> irange spans, but adding this representation would allow the unification of the
> bit-based propagation performed in tree-ssa-ccp with the range-value based
> propagation performed in EVRP/ranger, allowing the clever forwards/backwards
> functionality.
>
> As Andrew's recent (partial) review points out, tracking the effect of operations
> like BIT_XOR_EXPR on VR_RANGE is much more complicated than on the
> proposed VR_NONZEROBITS.
>
> Alas, I'm not the sort of contributor to make large infrastructure changes
> myself, but if the above functionality were in place, I/the compiler would
> be able to make use of it.
>

And this is exactly what we are hoping.. we provide the structure and 
someone who is better at the underlying detail interaction can flesh out 
whatever specifics they find interesting.


Andrew