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
