This is the mail archive of the
mailing list for the GCC project.
Re: Ada subtypes and base types
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?