[Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103168

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
            Summary|[9/10/11/12 Regression]     |Value numbering for PRE of
                   |Value numbering for PRE of  |pure functions can be
                   |pure functions can be       |improved
                   |improved                    |

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #7)
> The testcase in comment #3 is optimized by GCC 6 but not by GCC 7 up.

That's beacause GCC 6 detected a::ret () as const while with GCC 7 and up it's
only pure.

;; Function a::ret (_ZN1a3retEi, funcdef_no=0, decl_uid=2371, cgraph_uid=1,
symbol_order=0)

 neither


 local analysis of static int a::ret(int)/0
   scanning: return v_1(D);
    checking previously known:
static int a::ret(int)/0 is not a malloc candidate, reason: Return value is not
SSA_NAME or not a pointer type.
Function is locally const.
Function found to be const: static int a::ret(int)/0
Dropping state to PURE because function does not bind to current def.
Declaration updated to be const: static int a::ret(int)/0
__attribute__((noinline))
int a::ret (int v)
{
  <bb 2> [local count: 1073741824]:
  return v_1(D);

}

the comment in the code says

  /* Consider function:

     bool a(int *p)
     { 
       return *p==*p;
     }

     During early optimization we will turn this into:

     bool a(int *p)
     { 
       return true;
     }

     Now if this function will be detected as CONST however when interposed it
     may end up being just pure.  We always must assume the worst scenario
here.
   */

so indeed that's an issue.  So it's a bug fixed, not an optimization
regression.