[LLVMdev] removing unnecessary ZEXT

Robert Lytton robert at xmos.com
Wed Sep 11 07:22:03 PDT 2013


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/20130911/0e2f65e1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm-strcspn.s
Type: application/octet-stream
Size: 1710 bytes
Desc: arm-strcspn.s
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130911/0e2f65e1/attachment.obj>


More information about the llvm-dev mailing list