6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-01-28 06:32:09 +00:00
Code Issues Projects Releases Wiki Activity

New note about something bad happening in target independent optimizers

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28170 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Nate Begeman 2006-05-08 20:08:28 +00:00
parent d8624ed07f
commit fcf64a91d6
1 changed files with 18 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
lib/Target/PowerPC/README.txt
View File

@ -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 ; <uint> [#uses=3]
%tmp1 = shr uint %tmp, ubyte 31 ; <uint> [#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.