https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71726
Bug ID: 71726
Summary: Simplify (intptr_t)p+4-(intptr_t)(p+4)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00010.html
#include <stdint.h>
intptr_t f(char*p){return (intptr_t)p+4-(intptr_t)(p+4);}
We only manage to simplify this to return 0 in RTL. "maybe we can value-number
it
the same with some tricks" but that would not help for
(intptr_t)p+8-(intptr_t)(p+4), or even for (intptr_t)(p+4)-4-(intptr_t)p.
"to handle (long)p + 4 - (long)(p + 4) the only thing we need is to
transform (long)(p + 4) to (long)p + 4 ... that would simplify things but
of course we cannot ever undo that canonicalization if the result is
ever converted back to a pointer." Indeed, I don't know if on average it would
be a win or a loss (I'd bet a little on "win").
Easiest seems to be to add a few more match.pd patterns as we hit them in real
code, and hope they cover enough cases that we can forget about the rest for a
while, until someone enhances reassoc.
