Re: [PATCH 2/2] VR-VALUES: Rewrite test_for_singularity using range_op_handler

[Jeff Law <jeffreyalaw@gmail.com>]

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
> 
>