https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #19 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
Tracked down the problem in 176.gcc to a difference in the generated code for
benchmark source toplev.c:exact_log2_wide(). Following compiled with -O3
-mcpu=power7.
int exact_log2_wide (unsigned int x)
{
register int log = 0;
if (x == 0 || x != (x & -x))
return -1;
while ((x >>= 1) != 0)
log++;
return log;
}
r212351:
neg 9,3
and 9,9,3
cmplw 7,9,3
bne 7,.L5
>>> rldicl. 9,9,63,33
li 3,0
beq 0,.L6
r212352:
neg 10,3
and 10,10,3
cmplw 7,10,3
bne 7,.L5
>>> srdi. 9,3,1
li 3,0
beq 0,.L6
r212351 is clearing the high word of the 64-bit register on the initial shift
right of 'x', whereas r212352 just starts shifting the whole 64-bit reg. The
reason this causes problems is that the callers are calling with an integer
arg:
#define exact_log2(N) exact_log2_wide ((HOST_WIDE_INT) (N))
So in the case where MIN_INT32 is passed (sign extended), the upper 32 bits are
'1' so r212352 returns a value of 63 whereas prior revisions returned a value
of 31.
Not sure if this is more of a benchmark source error, but figured I'd post my
findings in case it helps with the general problem.
