This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
redundancy in gimplify_compound_lval?
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 15 May 2007 00:05:34 +0200
- Subject: redundancy in gimplify_compound_lval?
Does anyone have an opinion on the following apparently redundant stuff?
static enum gimplify_status
gimplify_compound_lval (tree *expr_p, tree *pre_p,
tree *post_p, fallback_t fallback)
[...]
So we do this in three steps. First we deal with the annotations
for any variables in the components, then we gimplify the base,
then we gimplify any indices, from left to right. */
for (i = VEC_length (tree, stack) - 1; i >= 0; i--)
{
tree t = VEC_index (tree, stack, i);
[...]
/* Step 2 is to gimplify the base expression. Make sure lvalue is set
so as to match the min_lval predicate. Failure to do so may result
in the creation of large aggregate temporaries. */
tret = gimplify_expr (p, pre_p, post_p, is_gimple_min_lval,
fallback | fb_lvalue);
ret = MIN (ret, tret);
[...]
/* And finally, the indices and operands to BIT_FIELD_REF. During this
loop we also remove any useless conversions. */
for (; VEC_length (tree, stack) > 0; )
{
[...]
tret = gimplify_expr (p, pre_p, post_p, is_gimple_min_lval, fallback);
ret = MIN (ret, tret);
So there seems to be a 4th step and it (poorly) mimics the 2nd. The revision
history shows that this 4th step predates the 2nd.
--
Eric Botcazou