On Fri, Jun 22, 2018 at 11:13 AM Kugan Vivekanandarajah
<[email protected]> wrote:
>
> [PATCH 1/3][POPCOUNT] Handle COND_EXPR in expression_expensive_p
This says that COND_EXPR itself isn't expensive. I think we should
constrain that a bit.
I think a good default would be to only allow a single COND_EXPR which
you can achieve
by adding a bool in_cond_expr_p = false argument to the function, pass
in_cond_expr_p
down and pass true down from the COND_EXPR handling itself.
I'm not sure if we should require either COND_EXPR arm (operand 1 or
2) to be constant
or !EXPR_P (then multiple COND_EXPRs might be OK).
The main idea is to avoid evaluating many expressions but only
choosing one in the end.
The simplest patch achieving that is sth like
+ if (code == COND_EXPR)
+ return (expression_expensive_p (TREE_OPERAND (expr, 0))
|| (EXPR_P (TREE_OPERAND (expr, 1)) && EXPR_P
(TREE_OPERAND (expr, 2)))
+ || expression_expensive_p (TREE_OPERAND (expr, 1))
+ || expression_expensive_p (TREE_OPERAND (expr, 2)));
OK with that change.
Richard.
> gcc/ChangeLog:
>
> 2018-06-22 Kugan Vivekanandarajah <[email protected]>
>
> * tree-scalar-evolution.c (expression_expensive_p): Handle COND_EXPR.
