This is the mail archive of the
mailing list for the GCC project.
Re: Ada subtypes and base types
- From: Michael Matz <matz at suse dot de>
- To: Jeffrey A Law <law at redhat dot com>
- Cc: Waldek Hebisch <hebisch at math dot uni dot wroc dot pl>, gcc at gcc dot gnu dot org
- Date: Wed, 15 Mar 2006 17:57:06 +0100 (CET)
- Subject: Re: Ada subtypes and base types
- References: <E1FDnj3email@example.com> <firstname.lastname@example.org>
On Mon, 13 Mar 2006, Jeffrey A Law wrote:
> > What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> > allowed by given type.
> As long as you're *absolutely* clear that a variable with a
> restricted range can never hold a value outside that the
> restricted range in a conforming program, then I'll back off
> the "abuse" label and merely call it pointless :-)
I really really can't understand your strong opposition against the
sensible semantics of TYPE_MAX_VALUE. If the type has only a certain
range, than it obviously is a good thing to make this knowledge available
to the optimizers, even if that range doesn't end at a power of two. That
the value of variables of that type has to stay in that range is a
tautology (i.e. whereever that's not the case it's a bug somewhere, either
in the source, in the frontend or the optimizer). It doesn't make the
notion of TYPE_MAX_VALUE pointless at all.
> The scheme you're using "promoting" to a base type before all
> arithmetic creates lots of useless type conversions and means
> that the optimizers can't utilize TYPE_MIN_VALUE/TYPE_MAX_VALUE
> anyway. ie, you don't gain anything over keeping that knowledge
> in the front-end.
Sure it can, namely in VRP, and connected optimizations. First: It's not
clear that also the pascal frontend goes back to the base type for doing
arithmetics. In fact you assume that arithmetics is done on such
variables at all, which is not necessary. It can just be used as lookup
value in switches for instance, or in comparisons. And second: even if it
does promote to do arithmetics the final result probably is again in the
restricted type, again providing the knowledge of the range to VRP
(obviously the frontend has to somehow make sure that the result of this
arithmetic indeed fits into the real type, but see above for why this is
not a very special request).