On Fri, Mar 18, 2022 at 2:07 PM Andrew MacLeod <amacl...@redhat.com> wrote:
>
> 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.
Yes, for the next stage1 I have patches queued up to provide nonzero
bits within the irange object.
In working on providing a global range storage (an irange replacement
for SSA_NAME_RANGE_INFO) for the next release, it became clear that
nonzero and ranges are probably best suited to live in the same space.
The current global range mechanism already does this-- by refining
nonzero bits with each change to the range for an SSA name. However,
we sometimes pessimize global ranges, presumably because we couldn´t
properly represent an intersection with our value_range anti-range
business. Also, this nonzero+range symbiosis only currently works for
global ranges (not iranges or value_ranges). In the upcoming work,
the nonzero bits will live in irange, and work in tandem-- for
example, sometimes refining the range when a new nonzero mask is
available (0xff is really [0,255]) etc. I have the core
infrastructure done. I could probably use range-op help from the
relevant experts when the time comes.
And yes, as Roger points out, the mask tracking bits in CCP could play
very well with the ranger world. For that matter, while I was doing
the above work I noticed that many of the bitmasks that CCP could
determine, would eventually be figured out by evrp, just in the form
of ranges. Having nonzero bits in irange opens up all sorts of
possibilities.
>
>
> > 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.
Yup. We´re on the other side of the spectrum, the ability to provide
infrastructure with little expertise in the fine details (range ops,
floats, etc). :-)
Aldy
>
>
> Andrew
>
