On Mon, Mar 21, 2011 at 6:48 PM, Eric Botcazou <ebotca...@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 >
