http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660
--- Comment #11 from Jan Hubicka <hubicka at ucw dot cz> ---
> > case INTEGER_TYPE: case ENUMERAL_TYPE: case BOOLEAN_TYPE:
> > case OFFSET_TYPE:
> > + if (TREE_CODE (arg) == TRUTH_ORIF_EXPR)
> > + return fold_build2_loc (loc, TRUTH_ORIF_EXPR, type, TREE_OPERAND (arg,
> > 0),
> > TREE_OPERAND (arg, 1));
> > if (TREE_CODE (arg) == INTEGER_CST)
> > {
> > tem = fold_convert_const (NOP_EXPR, type, arg);
>
> This looks bogus. See where we do this folding and instead handle it
> there (I suspect gimple_boolify?)
I believe this transform apply for generic/FE trees, too. But indeed I also
think
it is not right spot, I just failed to quickly identify better.
I will check gimple_boolify.
> > - /* Build the new then clause, `tmp = then_;'. But don't build the
> > - assignment if the value is void; in C++ it can be if it's a throw. */
> > - if (!VOID_TYPE_P (TREE_TYPE (then_)))
> > - TREE_OPERAND (expr, 1) = build2 (MODIFY_EXPR, type, tmp, then_);
> > + /* Convert (A||B) ? true : false
> > + as A ? tmp = true : tmp = B != 0. */
>
> So does it end up working for if (a || b || c)? Otherwise this looks
> sensible to me. (A&&B) ? true : false -> A ? tmp = B != 0 : tmp = false
> then?
a||b||c results in sane code (I already tested it). We need to also handle &&.
I implemented it and for some reason I end up producing more statements for
combine.c, so I think I may inhibit some other optimization - the later
functions
play with side effects. Will dig into this further.
Honza
