This is the mail archive of the 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 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).


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