[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