On Sun, Apr 12, 2009 at 9:37 AM, Eric Botcazou <ebotca...@adacore.com> wrote: >> I wonder what this exception in VRP looks like? > > I wasn't specifically referring to an exception in VRP. I think that, when > checks are off, it would be sufficient for gigi to emit sort of assertions > for arguments on function entry (like your VRP patch did) and for return > values on function calls; VRP would then just propagate them. > > Could ASSERT_EXPR be used for this purpose, i.e. could it be made a first > class GENERIC (or GIMPLE) expression that front-ends could emit (during > gimplification)?
Yes, we could do that. Though a simpler form may be preferable, like directly specifying a constant range/anti-range instead of encoding these in (multiple) ASSERT_EXPRs. I will think of something. As for Ada - both function entry and exit constraints will be checked by the caller/callee, correct? So that once you inline VRP should be able to derive the ranges from existing checks? Thus - a IPA VRP pass should be able to verify these properties across functions? >> I also wonder if adding a test to the gimplifier that all integral typed >> DECL types have NULL TREE_TYPE and TYPE_MIN/MAX_VALUE according to their >> TYPE_PRECISION would pass with your changes (there may be such odd cases >> with other frontends ...). > > Note that the changes don't eliminate subtypes (gigi generates the same > GENERIC code), their actual bounds are only made private to gigi and their > visible bounds set to that of the base type; IOW there is no lowering pass, > except for the gimplification that will remove unnecessary casts. > > I think that the invariant should be that all integral types that appear in > the code (types for declarations and expressions) have maximal bounds for > their precision; "range" types should only be descriptive. Yes, I agree. I volunteer to prepare a verification pass that asserts this property during gimplification. Thanks, Richard.
