Re: Ada subtypes and base types

[Duncan Sands <baldrick at free dot fr>]

Hi Jeff, thanks for the info.

> > I agree that this kind of special casing by the middle-end is all
> > wrong - the front-end should do it.
> I'd disagree.  While it may at first seem useful to have ASSERT_EXPRs
> live through the entire optimization pipeline, they're actually going
> to get in the way of a fair amount of simple optimizations, specifically
> copy propagation and the secondary optimizations exposed by 
> copy propagation.
> 
> 
> > 
> > <RANT>
> > Personally I think the Ada frontend should never pass types with
> > a restricted range to the middle-end (in Ada terms, this means
> > that the middle-end would only ever see base types).
> I certainly do agree with this -- I've been pretty vocal about
> that already :-)

That still leaves the problem of how the Ada front-end tells the
middle-end that a variable is known to be in a certain range.  Due
to the way the language works, the front-end often does know a useful
range, helpful for optimisation.  If using types with strange ranges
is out, and ASSERT_EXPRs aren't appropriate, what is left?  After
further thought, I'm not so against the use of these ranges as I was...

> > So that means that initialising variables to [TYPE_MIN,TYPE_MAX]
> > is likely not acceptable in general.
> No, the problems referenced above are latent bugs that need to
> be fixed.  They do not argue that initializing to [TYPE_MIN, TYPE_MAX]
> is the wrong direction.

You are right.

> What needs to drive the representational solution is the ability to
> get the optimizations we want without paying a hefty compile-time
> or maintenance penalty.

I'm playing with the code right now, getting rid of VR_VARYING.  Do
you have any suggestions for benchmarking it?

Ciao,

Duncan.