On Mar 16, 2006, at 8:47 PM, Chris Lattner wrote:> On Thu, 16 Mar 2006, Eric Kidd wrote: >> The duplicate loads appear at the top of the %regex6 and %regex2 >> blocks below. I've tried various alias analysis implementations >> either alone or in combination. > > LICM doesn't remove common subexpressions, also -load-vn doesn't > affect LICM. Try "-licm -load-vn -gcse" instead of "-load-vn -licm"That works! Thank you. The bytecodes look really good--not only are the loads eliminated, but the tests are actually reduced to a switch statement using '-anders-aa -load-vn -gcse -simplifycfg -instcombine': regex6: ; preds = %loop_test %c8 = load ubyte* %iter ; <ubyte> [#uses=1] switch ubyte %c8, label %loop_step [ ubyte 97, label %ret_true ubyte 98, label %ret_true ] Unfortunately, this generates really weird code on the LLVM 1.6 PowerPC backend: LBB_matches_1: ; regex6 lbz r4, 0(r3) LBB_matches_2: ; NodeBlock rlwinm r5, r4, 0, 24, 31 cmplwi cr0, r5, 98 blt cr0, LBB_matches_4 ; LeafBlock LBB_matches_3: ; LeafBlock1 rlwinm r4, r4, 0, 24, 31 cmpwi cr0, r4, 98 beq cr0, LBB_matches_8 ; ret_true b LBB_matches_5 ; NewDefault LBB_matches_4: ; LeafBlock rlwinm r4, r4, 0, 24, 31 cmpwi cr0, r4, 97 beq cr0, LBB_matches_8 ; ret_true LBB_matches_5: ; NewDefault LBB_matches_6: ; loop_step I'm particularly confused by the rlwinm instructions that keep turning up in PowerPC output, and the double test against 98. I don't have a problem or anything; I'm just trying to figure out what's going on. :-) In any case, many thanks for your help! Cheers, Eric
On Mar 17, 2006, at 7:54 AM, Eric Kidd wrote:> Unfortunately, this generates really weird code on the LLVM 1.6 > PowerPC backend: > > LBB_matches_1: ; regex6 > lbz r4, 0(r3) > LBB_matches_2: ; NodeBlock > rlwinm r5, r4, 0, 24, 31 > cmplwi cr0, r5, 98 > blt cr0, LBB_matches_4 ; LeafBlock > LBB_matches_3: ; LeafBlock1 > rlwinm r4, r4, 0, 24, 31 > cmpwi cr0, r4, 98 > beq cr0, LBB_matches_8 ; ret_true > b LBB_matches_5 ; NewDefault > LBB_matches_4: ; LeafBlock > rlwinm r4, r4, 0, 24, 31 > cmpwi cr0, r4, 97 > beq cr0, LBB_matches_8 ; ret_true > LBB_matches_5: ; NewDefault > LBB_matches_6: ; loop_step > > I'm particularly confused by the rlwinm instructions that keep > turning up in PowerPC output, and the double test against 98. I > don't have a problem or anything; I'm just trying to figure out > what's going on. :-)Ah! The backend is running -lowerswitch, which does a binary search of the case labels (even when there's only two of them). If I run -lowerswitch manually, though, I *do* get some very nice results out of -cee. :-) It's automatically killing some backtrack nodes in my CFG, which is a big (and unexpected) win. Overall, I'm extremely impressed with the LLVM optimizer framework-- even when it does something weird, it's easy to dive in and read the code. In the past, I've spent months working on compiler backends before feeling this comfortable. Cheers, Eric
On Fri, 17 Mar 2006, Eric Kidd wrote:>> LICM doesn't remove common subexpressions, also -load-vn doesn't affect >> LICM. Try "-licm -load-vn -gcse" instead of "-load-vn -licm" > > That works! Thank you. The bytecodes look really good--not only are the loads > eliminated, but the tests are actually reduced to a switch statement using > '-anders-aa -load-vn -gcse -simplifycfg -instcombine': > > regex6: ; preds = %loop_test > %c8 = load ubyte* %iter ; <ubyte> [#uses=1] > switch ubyte %c8, label %loop_step [ > ubyte 97, label %ret_true > ubyte 98, label %ret_true > ] > > Unfortunately, this generates really weird code on the LLVM 1.6 PowerPC > backend: > > LBB_matches_1: ; regex6 > lbz r4, 0(r3) > LBB_matches_2: ; NodeBlock > rlwinm r5, r4, 0, 24, 31 > cmplwi cr0, r5, 98 > blt cr0, LBB_matches_4 ; LeafBlock > LBB_matches_3: ; LeafBlock1 > rlwinm r4, r4, 0, 24, 31 > cmpwi cr0, r4, 98 > beq cr0, LBB_matches_8 ; ret_true > b LBB_matches_5 ; NewDefault > LBB_matches_4: ; LeafBlock > rlwinm r4, r4, 0, 24, 31 > cmpwi cr0, r4, 97 > beq cr0, LBB_matches_8 ; ret_true > LBB_matches_5: ; NewDefault > LBB_matches_6: ; loop_step > > I'm particularly confused by the rlwinm instructions that keep turning up in > PowerPC output, and the double test against 98. I don't have a problem or > anything; I'm just trying to figure out what's going on. :-)FWIW, the rlwinm instructions are because the code generator isn't keep track, across basic blocks, that the byte value, stored in a 32-bit register, has its top part already zeroed. The redundant compares against 98 are actually different compares (lt vs eq) and LLVM isn't CSE'ing them in this case. FWIW, Nate is actually currently working on replacing the lower switch pass. :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Fri, 17 Mar 2006, Eric Kidd wrote:>> I'm particularly confused by the rlwinm instructions that keep turning up >> in PowerPC output, and the double test against 98. I don't have a problem >> or anything; I'm just trying to figure out what's going on. :-) > > Ah! The backend is running -lowerswitch, which does a binary search of the > case labels (even when there's only two of them).yup> If I run -lowerswitch manually, though, I *do* get some very nice results out > of -cee. :-) It's automatically killing some backtrack nodes in my CFG, which > is a big (and unexpected) win.Great. Note that -cee is a beta pass... it has some known bugs and isn't planned to be worked on in the immediate future. :(> Overall, I'm extremely impressed with the LLVM optimizer framework--even when > it does something weird, it's easy to dive in and read the code. In the past, > I've spent months working on compiler backends before feeling this > comfortable.Great! I'm glad to hear that! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Seemingly Similar Threads
- [LLVMdev] Stupid '-load-vn -licm' question (LLVM 1.6)
- [LLVMdev] Stupid '-load-vn -licm' question (LLVM 1.6)
- [LLVMdev] Stupid '-load-vn -licm' question (LLVM 1.6)
- [LLVMdev] Stupid '-load-vn -licm' question (LLVM 1.6)
- [LLVMdev] Stupid '-load-vn -licm' question (LLVM 1.6)