On Wed, Nov 2, 2022 at 10:55 AM Tamar Christina <[email protected]> wrote:
>
> Hi Aldy,
>
> I'm trying to use Ranger to determine if a range of an expression is a single
> bit.
>
> If possible in case of a mask then also the position of the bit that's being
> checked by the mask (or the mask itself).
Just instantiate a ranger, and ask for the range of an SSA name (or an
arbitrary tree expression) at a particular gimple statement (or an
edge):
gimple_ranger ranger;
int_range_max r;
if (ranger.range_of_expr (r, <SSA_NAME>, <STMT>)) {
// do stuff with range "r"
if (r.singleton_p ()) {
wide_int num = r.lower_bound ();
// Check the bits in NUM, etc...
}
}
You can see the full ranger API in gimple-range.h.
Note that instantiating a new ranger is relatively lightweight, but
it's not free. So unless you're calling range_of_expr sporadically,
you probably want to have one instance for your pass. You can pass
around the gimple_ranger around your pass. Another way of doing this
is calling enable_rager() at pass start, and then doing:
get_range_query (cfun)->range_of_expr (r, <SSA_NAME>, <STMT>));
gimple-loop-versioning.cc has an example of using enable_ranger /
disable_ranger.
I am assuming you are interested in ranges for integers / pointers.
Otherwise (floats, etc) you'd have to use "Value_Range" instead of
int_range_max. I can give you examples on that if necessary.
Let me know if that helps.
Aldy
>
> Do you have any pointers/existing code I can look at to do this?
>
> Kind regards,
> Tamar
>
> > -----Original Message-----
> > From: Jeff Law <[email protected]>
> > Sent: Tuesday, November 1, 2022 5:00 PM
> > To: Tamar Christina <[email protected]>; [email protected]
> > Cc: nd <[email protected]>; [email protected]
> > Subject: Re: [PATCH 1/2]middle-end: Add new tbranch optab to add support
> > for bit-test-and-branch operations
> >
> >
> > On 11/1/22 09:53, Tamar Christina wrote:
> > >>
> > >>> from the machine description.
> > >>>
> > >>> +@cindex @code{tbranch@var{mode}4} instruction pattern @item
> > >>> +@samp{tbranch@var{mode}4} Conditional branch instruction
> > combined
> > >>> +with a bit test-and-compare instruction. Operand 0 is a comparison
> > >>> +operator. Operand 1 is the operand of the comparison. Operand 2 is
> > >>> +the bit position of Operand 1 to test.
> > >>> +Operand 3 is the @code{code_label} to jump to.
> > >> Should we refine/document the set of comparison operators allowed?
> > >> Is operand 1 an arbitrary RTL expression or more limited? I'm
> > >> guessing its relatively arbitrary given how you've massaged the
> > >> existing branch-on-bit patterns from the aarch backend.
> > > It can be any expression in theory. However in practical terms we
> > > usually force the values to registers before calling the expansion.
> > > My assumption is that this is for CSE purposes but that's only a guess.
> >
> > Understood. And generally yes, forcing expressions into regs is good for
> > CSE.
> >
> >
> > >
> > >> Do we have enough information lying around from Ranger to avoid the
> > need
> > >> to walk the def-use chain to discover that we're masking off all but one
> > bit?
> > >>
> > > That's an interesting thought. I'll try to see if I can figure out how
> > > to query
> > > Ranger here. It would be nice to do so here.
> >
> > Reach out to Aldy, I suspect he can probably give you the necessary
> > pseudocode pretty quickly.
> >
> >
> > Jeff
> >
>
