On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote: > On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote: > > > Hi Jeff, on the subject of seeing through typecasts, I was playing around > > with VRP and noticed that the following "if" statement is not eliminated: > > > > int u (unsigned char c) { > > int i = c; > > > > if (i < 0 || i > 255) > > return -1; /* never taken */ > > else > > return 0; > > } > > > > Is it supposed to be? > Fixed thusly. Bootstrapped and regression tested on i686-pc-linux-gnu.
Hi Jeff, while your patch catches many cases, the logic seems a bit wonky for types with TYPE_MIN/TYPE_MAX different to those that can be deduced from TYPE_PRECISION. For example, there is nothing stopping inner_type having a bigger TYPE_PRECISION than outer_type, but a smaller [TYPE_MIN,TYPE_MAX] range. For example, outer_type could be a byte with range 0 .. 255, and inner_type could be an integer with range 10 .. 20. I think this logic: ! if (vr0.type == VR_RANGE ! || (vr0.type == VR_VARYING ! && TYPE_PRECISION (outer_type) > TYPE_PRECISION (inner_type))) ! { ! tree new_min, new_max, orig_min, orig_max; should really test whether TYPE_MAX (inner_type) < TYPE_MAX (outer_type) || TYPE_MIN (inner_type) > TYPE_MIN (outer_type) and take the appropriate action if so. By the way, I hacked tree-vrp to start all value ranges for INTEGRAL_TYPE_P variables to [TYPE_MIN, TYPE_MAX]. It certainly helps with eliminating many Ada range checks. Maybe the compiler will even bootstrap :) This approach has advantages, even if TYPE_MIN/MAX are those given by TYPE_PRECISION. For example, after incrementing a variable you automatically get the range [TYPE_MIN+1,INF]. The approach also has disadvantages: for example, the notion of an "interesting" range has to be adjusted, since now VR_RANGE can be pretty uninteresting; and how interesting is [TYPE_MIN+1,INF] in practice? Also, there's likely to be extra overhead, due to pointless computations and comparisons on [TYPE_MIN, TYPE_MAX] ranges, especially if they are symbolic. Furthermore, in the case of symbolic TYPE_MIN and/or TYPE_MAX, it may be possible to deduce better ranges using the max/min range given by TYPE_PRECISION, since these are compile time constants, rather than using [TYPE_MIN,TYPE_MAX]. As I final thought, it struck me that it might make sense to associate the range [TYPE_MIN, TYPE_MAX] to the type (rather than to variables of the type), and extend the notion of equivalence so that a variable's range can be equivalent to the range of it's type. This is probably nonsensical, but I can't tell given my current minuscule understanding of VRP ;) All the best, Duncan.