From fcf64a91d65ece1168c2108271c4b2c7e4271e5e Mon Sep 17 00:00:00 2001 From: Nate Begeman Date: Mon, 8 May 2006 20:08:28 +0000 Subject: New note about something bad happening in target independent optimizers git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28170 91177308-0d34-0410-b5e6-96231b3b80d8 --- lib/Target/PowerPC/README.txt | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) (limited to 'lib/Target/PowerPC/README.txt') diff --git a/lib/Target/PowerPC/README.txt b/lib/Target/PowerPC/README.txt index 21d0165077..fb6eca5da5 100644 --- a/lib/Target/PowerPC/README.txt +++ b/lib/Target/PowerPC/README.txt @@ -492,8 +492,6 @@ transformation, good for PI. See PPCISelLowering.cpp, this comment: ===-------------------------------------------------------------------------=== -Another missed rlwimi case: - void %foo(uint *%tmp) { %tmp = load uint* %tmp ; [#uses=3] %tmp1 = shr uint %tmp, ubyte 31 ; [#uses=1] @@ -529,3 +527,21 @@ _foo: or r2, r2, r4 stw r2, 0(r3) blr + +===-------------------------------------------------------------------------=== + +Distilled from the code above, something wacky is going in the optimizers before +code generation time... + +unsigned foo(unsigned x) { + return (unsigned)((unsigned char)(x >> 30) | (unsigned char)(x >> 31)) << 31; +} + +unsigned bar(unsigned x) { + return ((x >> 30) | (x >> 31)) << 31; +} + +generate different code when -O is passed to llvm-gcc. However, when no +optimization is specified and the output is passed into opt with just -mem2reg +and -instcombine, the good code comes out of both. Something is happening before +instcombine to confuse it, and not delete the no-op casts. -- cgit v1.2.3