On Mon, 12 Sep 2016, Igor Shevlyakov wrote:
Well, my concern is not what happens with overflow (which in second
case -fsanitize=undefined will address), but rather consistency of
that 2 cases.
p[x+1] generates RTL which leads to better generated code at the
expense of leading to overflow, while p[1+x] never overflows but leads
to worse code.
It would be beneficial to make the behaviour consistent between those 2 cases.
True. Your example with undefined behavior confused me as to what your
point was.
For
int* f1(int* p, int x) { return &p[x + 1]; }
int* f2(int* p, int x) { return &p[1 + x]; }
we get in the gimple dump
_1 = (sizetype) x;
_2 = _1 + 1;
vs
_1 = x + 1;
_2 = (long unsigned int) _1;
The second one is a better starting point (it has more information about
potential overflow), but the first one has the advantage that all numbers
have the same size, which saves an instruction in the end
movslq %esi, %rsi
leaq 4(%rdi,%rsi,4), %rax
vs
addl $1, %esi
movslq %esi, %rsi
leaq (%rdi,%rsi,4), %rax
We regularly discuss the potential benefits of a pass that would try to
uniformize integer sizes...
In the mean time, I agree that gimplifying x+1 and 1+x differently makes
little sense, you could file a PR about that.
--
Marc Glisse
