This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Remove VRPs use of TYPE_MIN/MAX_VALUE
On Mon, 11 Apr 2011, Eric Botcazou wrote:
> > The middle-end treats conversions between integral types that differ
> > in TYPE_MIN/MAX_VALUE but not in TYPE_PRECISION or signedness as useless.
> > This is inconsistent with VRP extracting range information from such
> > types (and it is not clear how NOP conversions behave here anyway).
>
> IIRC we agreed, by the time I fixed the Ada compiler, that the IL shouldn't
> contain types with non-canonical bounds, except for constructs that don't
> generate code like the TYPE_DOMAIN of arrays. My understanding is that this
> has been the case (modulo bugs) for some time now, so I don't understand your
> remark about NOP conversions.
Such types are still there for enumeral type kinds. Also the C family
frontends leak arithmetic in array TYPE_DOMAIN types.
> > The following patch thus simply removes VRPs looking at TYPE_MIN/MAX_VALUE
> > in favor of using a canonical min/max value based on signedness and
> > precision. This exposes a latent bug in upper_bound_in_type and
> > lower_bound_in_type which do not properly sign-extend sizetype constants.
>
> Wouldn't it be better performance-wise to keep using TYPE_MIN/MAX_VALUE and add
> an appropriate check for non-standard types at the end of gimplification?
I don't see how we can do this for ENUM types. We use the
TYPE_MIN/MAX_VALUEs for debug information.
I tried to assert this for INTEGER_TYPEs only, but as noted above the
C family leaks TYPE_DOMAIN arithmetic.
Richard.