[LLVMdev] Stupid '-load-vn -licm' question (LLVM 1.6)

[Chris Lattner]

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/