[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
Mon Nov 22 12:54:44 GMT 2021
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.
More information about the Gcc-bugs
mailing list