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.
