On Mon, Jan 18, 2016 at 10:53:41AM -0500, Jason Merrill wrote:
> In this testcase, we weren't getting the benefits of fold's cleverness in
> handling COND_EXPR because we were only calling fold_for_warn on the
> condition itself. This patch changes check_function_arguments_recurse to
> fold the entire COND_EXPR, and also fixes cp_fold to actually fold
> COND_EXPR.
>
> Along with this, I've cleaned up some other bits I noticed in cp_fold: there
> was various unnecessary special-casing for unary and binary ops as well, and
> we were clobbering an input CONSTRUCTOR rather than returning a new folded
> one.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
Guess too late for GCC 6, but I'm slightly worried about fold_for_warn
compile time complexity, if we have very large trees of expressions and try
to fold_for_warn it all, then on the original fold_for_warn 2-3 operands
thereof and so on, with something foldable somewhere very deep in the trees.
For that perhaps best would be if we cache cp_fold results on
expressions somewhere (custom tree that holds original and corresponding
folded expression, or hash table, whatever) and if we try to cp_fold it
again, we just reuse what we've folded it to last time.
Jakub
