Re: [patch] fold-const.c: Reorganize fold - Part 18/n (Take 2)

[Kazu Hirata <kazu at cs dot umass dot edu>]

Hi Roger,

> It looks like you're overlooking the NOP_EXPRs that can also occur
> between the ADDR_EXPR and the FUNCTION_DECL.  For example, if you
> look at the implementation of get_callee_fndecl, you'll see
> 
>   /* The first operand to the CALL is the address of the function
>      called.  */
>   addr = TREE_OPERAND (call, 0);
> 
>   STRIP_NOPS (addr);
>   ^^^^^^^^^^^^^^^^^^

I am aware of the STRIP_NOPS there, but by the time we call
get_callee_fndecl, we know that we have a FUNCTION_DECL directly
wrapped by ADDR_EXPR (without any NOPs), so neither the STRIP_NOP nor
the "if" statement involving DECL_INITIAL does anything.

> What I'd prefer to see is the existing code changed from:
> 
> >   if (TREE_CODE (op0) == ADDR_EXPR
> >       && TREE_CODE (TREE_OPERAND (op0, 0)) == FUNCTION_DECL
> >       && DECL_BUILT_IN (TREE_OPERAND (op0, 0)))
> >     {
> >       tree fndecl = get_callee_fndecl (t);
> 
> to something like:
> 
>     fndecl = get_callee_fndecl_1 (op0);
>     if (fndecl
>         && TREE_CODE (fndecl) == FUNCTION_DECL
>         && DECL_BUILT_IN (fndecl)
>       {
>         ...
> 
> 
> However, this is just to catch the missed optimization opportunities
> that we're currently missing.  I'll agree that your current clean-up
> is no worse than what we have at the moment, so it's OK for mainline.
> However, if at some point in the future we can get fold_ternary to
> optimize through the NOP_EXPRs, and DECL_INITIALs and front-end
> specific indirection then that would clearly be an improvement.

Yes, I understand your concern, but the tree optimizers do a lot of
propagation, including replacements of indirect calls with direct ones
in a more general setting.  That is, propagation of DECL_INITIAL is
not limited to the first operand of CALL_EXPR, so I don't think we
should try to catch more here in fold_ternary or in get_callee_decl.
We should just wait until ADDR_EXPR<FUNCTION_DECL> is propagated into
the first operand of a CALL_EXPR.  When that propagation happens, we
can then invoke fold_builtin to do its job.  See

  http://gcc.gnu.org/ml/gcc/2005-03/msg01011.html

> To summarise, this patch is approved for mainline.

Thank you.  If you could also approve part 19, that would be greatly
appreciated.

  http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02039.html

Kazu Hirata