[LLVMdev] removing unnecessary ZEXT

Robert Lytton robert at xmos.com
Tue Sep 10 08:59:24 PDT 2013


Hi,

A bit more information.
I believe my problem lies with the fact that the load is left as 'anyext from i8'.
On the XCore target we know this will become an 8bit zext load - as there is no 8bit sign extended load!
If BB#1 were to force the load to a "zext from i8" would this information be available in BB#2?

BB#1:
    0x268c1b0: i32 = Register %vreg1 [ID=3]
    0x2689d80: i32,ch = load 0x265d380, 0x2689f80, 0x268b9b0<LD1[%s2], anyext from i8> [ORD=4] [ID=5]
  0x2689e80: ch = CopyToReg 0x265d380, 0x268c1b0, 0x2689d80 [ORD=4] [ID=6]

BB#2:
            0x268a480: i32 = Register %vreg1 [ID=1]
          0x268bbb0: i32,ch = CopyFromReg 0x265d380, 0x268a480 [ORD=6] [ID=7]
          0x268a080: i32 = Constant<255> [ID=6]
        0x268bdb0: i32 = and 0x268bbb0, 0x268a080 [ORD=6] [ID=8]
        0x2689e80: i32 = Constant<0> [ID=5]
        0x268c1b0: ch = seteq [ID=2]
      0x268a880: i32 = setcc 0x268bdb0, 0x2689e80, 0x268c1b0 [ORD=6] [ID=9]

Robert

________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Robert Lytton [robert at xmos.com]
Sent: 06 September 2013 17:18
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] removing unnecessary ZEXT

Hi,

Within a basic block I can remove unnecessary register copies + zero sign extensions of  unsigned-8bit-loaded values by implementing isZExtFree() for ISD::LOAD nodes.
...But not between basic blocks.

The first block does a CopyFromReg of the unsigned-8bit-loaded vreg1 into a new vreg2.
The second block then does a unnecessary zext to vreg2.
What I want is the 2nd block to use the original vreg1!
What I am getting is one extra register clobber and two extra instructions.

I have looked at other targets to see what they do but can't see what I am missing.

Help please!
Thank you

Robert






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/c4103be5/attachment.html>


More information about the llvm-dev mailing list