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

[Roger Sayle <roger at eyesopen dot com>]

On Tue, 22 Mar 2005, Kazu Hirata wrote:
> Roger Sayle suggested offline that I should retain a call to
> get_callee_fndecl in the CALL_EXPR case of fold_ternary, but I don't
> think we need that.  If we "inline" get_callee_fndecl into the
> following piece of code and optimize away useless code,
>
>   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);
>
> we would get
>
>   if (TREE_CODE (op0) == ADDR_EXPR
>       && TREE_CODE (TREE_OPERAND (op0, 0)) == FUNCTION_DECL
>       && DECL_BUILT_IN (TREE_OPERAND (op0, 0)))
>     {
>       tree fndecl = TREE_OPERAND (op0, 0);

Hi Kazu,

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);
  ^^^^^^^^^^^^^^^^^^

For an example, of why we need this see the following post:
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg01140.html
and the following thread at
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg01148.html


This is in addition to the lang_hooks.lang_get_callee_fndecl (call)
and the optimizations for DECL_INITIAL in get_callee_fndecl.


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.

To summarise, this patch is approved for mainline.

Roger
--