[patch] Couple of tweaks to the gimplifier

[Richard Guenther]

On Mon, Mar 21, 2011 at 6:48 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> >  1) Set TREE_THIS_NOTRAP on the INDIRECT_REF built for VLA decls.  This
>> > is correct since stack memory isn't considered as trapping in the IL.
>>
>> This is ok.
>
> Thanks.
>
>> >  2) Improve gimplification of complex conditions in COND_EXPR.  They are
>> >     naturally generated by the Ada compiler and the patch avoids emitting
>> >     redundant branches in GIMPLE, visible at -O0 for the testcase:
>>
>> Shouldn't
>>
>> +  /* Remove any COMPOUND_EXPR so the following cases will be caught.  */
>> +  STRIP_TYPE_NOPS (TREE_OPERAND (expr, 0));
>> +  if (TREE_CODE (TREE_OPERAND (expr, 0)) == COMPOUND_EXPR)
>> +    gimplify_compound_expr (&TREE_OPERAND (expr, 0), pre_p, true);
>>
>> happen in gimple_boolify instead so that other callers also benefit?
>> That is, add a COMPOUND_EXPR case there?
>
> Not clear to me.  gimple_boolify doesn't gimplify, it boolifies, i.e. only does
> type conversions to boolean.  This looks orthogonal.
>
>> So, what does the GENERIC look like here?
>
> Attached.  Barely readable, like pretty much all GENERIC for Ada, but you can
> see the big IF statement with the COMPOUND_EXPR on the RHS of the &&.

So looking at the GENERIC I fail to see how the patch would handle
the COMPOUND_EXPR which is in operand 1 of the &&.  That's also
one reason I suggested gimple_boolify instead, as that works recursively
on the predicate.  Of course you are right, gimple_boolify doesn't seem to
be prepared to do gimplification.

Ok, debugging.

Ah, I see - we recursively gimplify the pieces of the predicate.  So yes,
I think your patch makes sense.

Thus, ok.

Thanks,
Richard.

> --
> Eric Botcazou
>