On 5/23/25 8:56 AM, Andrew MacLeod wrote:
Since the PR scrolled by, i don't think I ever noticed this thread.. or
at least where it lead.
This is not an "equivalence" that ranger would propagate because its a
relation with a constant.
the issue here seems to be:
if (x < 4) when x has a range something like [0,0][10, 40][30, +INF]
on the true edge, we will propagate the RANGE [0,0] for x and any pass
which queries the range of x will get [0,0], just as if if was if (x == 0)
likewise, on the false edge we'll propagate x = [10,40][30, +INF]
so although we don't propagate an *equivalence* as such, any pass which
queries the range of X will get the [0,0] range one expects.
Which is as good as propagation I think since a query for the range
returns a singleton, so if we had a subsequent dest = a + x we'd
simplify that to just dest = a.
As for the transformation... Perhaps what we are really interested in
checking here is whether all further uses of x after this statement are
dominated by one edge of the condition, in which case you do the
transformation to the check for a singularity. or you could check
that there are no dominated uses on the OTHER side of of the condition
that might utilize the lost information.. if no one used x on the false
side.. it doesn't matter.
I just think we want the transformation to go away. The only thing we
were trying to do was collapse it down to an EQ/NE so that we had an
equivalence on one arm that could then be used to optimize code on that
arm. Ranger gives us that same capability without the undesirable side
effects.
Jeff
Andrew
