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.
