This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ada subtypes and base types


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]