This is the mail archive of the gcc@gcc.gnu.org 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 Tue, 2006-03-28 at 23:49 +0200, Duncan Sands wrote:

> 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...
As I've stated before, I really don't think that we're gaining that
much from those front-end ranges and the way the front-ends are
generating code is likely getting in the way of more useful 
optimizations.

I haven't thought a whole lot about how to get the benefit of those
ranges without the penalties.  The only guidelines I can immediately
come up with are to not expose the subtypes to the optimizers except
for VRP.  ie, do *everything* in the base type and not emit all the
conversions between the base and sub types, then have some way for
VRP to query objects for subtype range information.

> I'm playing with the code right now, getting rid of VR_VARYING.  Do
> you have any suggestions for benchmarking it?
Most of us have a bucket of .i and .ii files that we use for compile
time testing.  You might even be able find a tarball of such files
on Diego's home page IIRC.

You might consider running those benchmarks with a compiler that
has enable-checking turned off.  You're not interested in the
checking bits and they'll just make it harder to find/interpret
any interesting results from your tests.


jeff



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