https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
Bug ID: 66552
Summary: Missed optimization when shift amount is result of
signed modulus
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Target: x86/generic
In code such as
unsigned f(unsigned x, int n)
{
return x >> (n % 32);
}
I think gcc should be allowed to assume that n is either positive or divisible
by 32 (i.e., that the result of the % is non-negative). So it should actually
compile this the same as it does x >> (n & 31). However, it seems to generate
code to compute the actual value of n%32 and then uses that.
Even if one doesn't want to optimize based on UB, this is silly on a platform
like x86: There, gcc already knows that the shift instruction only depends on
the lower 5 bits, and those 5 bits do not depend on the full result of the
modulus (whether following C99 or not).
