On 11/15/24 10:19, Jan Hubicka wrote:
I have seen this happen when the result of the intersection is an empty
set (one of the few comments in value-range.h actually describes an
undefined range as an "empty range"). I have only seen this happen when
the edge has been redirected to builtin_unreachable because, the has
been recognized as impossible. But I am not absolutely convinced we can
rely on that always being the case.
We can decide to not update jump functions for edges leading to
gcc_unreachable, after we have given some thought what to do about
reference description counts, but that is a separate effort, I'd say.
Hmm, I wonder in what scenarios empty range can happen. Probably we
could redirect such edges to unreachable since such code path can not be
taken?
It is however probably rare enough to not matter that much in practice.
Honza
Empty ranges invariably mean unreachable code.
if (x > 50) // range is [51, +INF]
if (x < 40) // range is [-INF, 40]
When the 2 calculated ranges intersect, we get UNDEFINED or the empty
range. It basically means on this path, X cannot have a range, which
makes it unreachable. You dont see it often because VRP, threading and
such often remove these situations before they are observed.
The only other time I think it can happen is when we are dealing with
uninitialized values. Sometimes if there is no definition, it can be
UNDEFINED.. this allows us to pick other values for it so we can do
optimizations. I think thats a special case we do however. I
*think* as a general user you will get VARYING for uninitialized
values. Looking through gimple_range_global() (which is used when no
value has been or can be calculated), any undefined values come back
VARYING.
After all that, I think you could redirect those edges to unreachable...
Andrew
