Hi, On Fri, Nov 15 2024, Jan Hubicka wrote: >> >> 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] > > This looks like something reasonably possible. I would expect some of > libstdc++ > checks which leads to various calls of throw can be eliminated by this.
yes. Moreover, in our case, each of such conditions comes from a different function which are becoming one during inlining, as part of which we perform the intersection... >> >> 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. ...so it is too early for intra-procedural optimizations to clean up. >> >> 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... > > Which sounds like a good idea then.. As I wrote in my email, in all the cases which I have manually examined, the edge has already been redirected to builtin_unreachable. If we feel like it, we can add a verifier that is always the case - I'd suggest doing that only early in a stage 1 though. Is the patch OK then? Thanks, Martin
