On Tue, 2006-03-28 at 01:03 +0200, Duncan Sands wrote:
> Hi Jeff,
>
> On Monday 27 March 2006 21:00, Jeffrey A Law wrote:
> > On Sat, 2006-03-25 at 10:35 -0500, Diego Novillo wrote:
> >
> > > Start by looking at tree-vrp.c:infer_value_range.
> > I'm not so sure this is the best place to start.
>
> it seems a good place for adding ASSERT_EXPRs on function return
> values though.
No. For assignments you really want to discover the range in
visit_assignment.
infer_value_range is really best suited for discovering ranges
that are implicit in the statement. For example, if a statement
dereferences a pointer, then you can infer that the pointer must
not be null. A conditional or switch statement allows you to
infer a value on one or more outgoing edges from the block
containing the conditional/switch.
> I agree, however I don't yet know how to walk the parameter list, so
> any hints would be welcome :)
Search for loops which iterate over DECL_ARGUMENTS. Here's an example
from function.c:
/* Process all parameters of the function. */
for (decl = DECL_ARGUMENTS (fndecl); decl; decl = TREE_CHAIN (decl))
{
instantiate_decl (DECL_RTL (decl));
instantiate_decl (DECL_INCOMING_RTL (decl));
if (DECL_HAS_VALUE_EXPR_P (decl))
{
tree v = DECL_VALUE_EXPR (decl);
walk_tree (&v, instantiate_expr, NULL, NULL);
}
}
But again, I would caution against going down this path without
first determining what we're going to do about the representational
issues we need to resolve. In fact, resolving those issues will
make insertion of ASSERT_EXPRs for the arguments a pointless exercise.
> 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 :-)
> Also, I now think it would be a mistake to initialise all
> variable ranges to [TYPE_MIN, TYPE_MAX]. I implemented this,
> and got great optimisation - a bit too much optimisation in fact!
> For example, you can't test whether a variable is in range using
> the obvious "if" statement anymore, since VRP will eliminate it
> (after all, it "knows" the variable is in range already, because
> it was told so).
Right, but that's exactly what you'd expect and exactly what
other optimizations in GCC already do. And if you've got such
a conditional, then it's clearly useless (which usually means
it's testing the wrong thing).
> Do the Ada people want this level of optimisation? I'm pretty sure
> they don't: I've heard Robert Dewar say that he considers exactly this
> optimisation (eliminating an "if" on an uninitialised variable based
> on the range given in the type definition) to be a bad idea.
There's definitely a corner case with Ada's uninitialized variables
which is unresolved (I didn't follow the discussion closely, so
perhaps they did come up with a solution).
> 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.
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.
Jeff
