[LLVMdev] removing unnecessary ZEXT

[Robert Lytton]

Hi

I've looked a bit more at the SelectionDAGBuilder.cpp and the use of AssertZext.

The isZExtFree() is called by RegsForValue::getCopyToRegs().
This correctly marks vreg as ZEXT when an unsigned 8 load.

The function that adds the ISD::AssertZext is RegsForValue::getCopyFromRegs().
It does this by checking the LOI->KnownZero.countLeadingOnes() for integer Vregs.
Hence, the EXT type needs to be known (and it to be in GetLiveOutRegInfo?)

If the vreg is a PHI node instruction, getCopyFromRegs()  does not look at the possible originators.
Is that because some originator vreg are in later BasicBlocks, so getCopyToRegs() has not yet been called and ZEXTed!
Is there a mechanism for sharing this information across blocks?
Is this the GetLiveOutRegInfo?...

Attached is a patch to output the following debug:
        $ llc -march=xcore test.ll -o -
        getCopyToRegs ZERO_EXTEND:   %.pre = load i8* %c, align 1
        getCopyFromRegs:  %0 = phi i8 [ %.pre, %entry ], [ %1, %if.end ]
                          %1 = load i8* %lsr.iv, align 1
                          %.pre = load i8* %c, align 1
                  did/will getCopyToRegs ZERO_EXTEND? Can we assume?
        getCopyToRegs ZERO_EXTEND:   %1 = load i8* %lsr.iv, align 1

I think I need to understand the intent of the code/data better before I can continue.
Any explanations most welcome.

Robert

p.s. can someone explain the following:

/// GetLiveOutRegInfo - Gets LiveOutInfo for a register, returning NULL if the
/// register is a PHI destination and the PHI's LiveOutInfo is not valid. If
/// the register's LiveOutInfo is for a smaller bit width, it is extended to
/// the larger bit width by zero extension. The bit width must be no smaller
/// than the LiveOutInfo's existing bit width.


________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Robert Lytton [robert at xmos.com]
Sent: 11 September 2013 15:22
To: Andrew Trick
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] removing unnecessary ZEXT

Hi Andrew,

Thank you for the suggestion.
I've looked at CodeGenPrepare.cpp and MoveExtToFormExtLoad() is never run.

I also notice that the ARM target produces the same additional register usage (copy) and zero extending (of the copy).
(See the usage of r3 &r5 and also r12 & r4 in attached file arm-strcspn.s, my understanding is that 'ldrb' is zero extending.)


Here is a simplified example:
    void test(const char *c) {
      do {
          if (!*c) break;
        ++c;
      } while (*c);
    }

And in IR form:
    define void @test(i8* nocapture %c) {
    entry:
      %.pre = load i8* %c, align 1
      br label %do.body
    do.body:
      %0 = phi i8 [ %.pre, %entry ], [ %1, %if.end ]
      %c.addr.0 = phi i8* [ %c, %entry ], [ %incdec.ptr, %if.end ]
      %tobool = icmp eq i8 %0, 0
      br i1 %tobool, label %do.end, label %if.end
    if.end:
      %incdec.ptr = getelementptr inbounds i8* %c.addr.0, i64 1
      %1 = load i8* %incdec.ptr, align 1
      %tobool1 = icmp eq i8 %1, 0
      br i1 %tobool1, label %do.end, label %do.body
    do.end:
      ret void
    }


The problem seems to be that an icmp becomes isolated in a different basic block to the originators of the vreg it uses viz:
    entry:
      %.pre = load i8* %c, align 1
    do.body:
      %0 = phi i8 [ %.pre, %entry ], [ %1, %if.end ]
      %tobool = icmp eq i8 %0, 0
    if.end:
      %1 = load i8* %incdec.ptr, align 1

When a vreg is promoted during legalization, I assume there is knowledge that the top bits are zero.
(assuming a ZEXTLOAD will be used - the only option for the xcore target)
But when a vreg is subsequently truncated, can the top bits be known? viz:
BB#1 'test:do.body'
            0x2c8d190: i32 = Register %vreg3
          0x2c8d590: i32,ch = CopyFromReg 0x2c5fcc0, 0x2c8d190 [ORD=4]
        0x2c8ce90: i8 = truncate 0x2c8d590 [ORD=4]
        0x2c8d990: i8 = Constant<0>
        0x2c8d890: ch = seteq
      0x2c8d390: i1 = setcc 0x2c8ce90, 0x2c8d990, 0x2c8d890 [ORD=4]

Is this what is happening?
Can the Type-legalizer discover this information when lowering the truncate?
Is the problem that this knowledge is not know in the DAG, only in the IR?

Robert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130912/de199430/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Patch_ZERO_EXTEND
Type: application/octet-stream
Size: 3318 bytes
Desc: Patch_ZERO_EXTEND
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130912/de199430/attachment.obj>