[llvm-dev] What does a dead register mean?
Gordon Keiser via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 6 03:38:12 PST 2018
A better explanation than I would have given is here:
https://groups.google.com/forum/#!topic/llvm-dev/NlGopW6_QxE
The optimization pass that would have eliminated that was turned off by -O0
so you see that behavior. At -O2 you get a tail call
TCRETURNdi64 <ga:@foo>, 0, <regmask %BH %BL %BP %BPL %BX %DI %DIL
%EBP %EBX %EDI %ESI %RBP %RBX %RDI %RSI %SI %SIL %R12 %R13 %R14 %R15 %XMM6
%XMM7 %XMM8 %XMM9 %XMM10 %XMM11 %XMM12 %XMM13 %XMM14 %XMM15 %R12B %R13B
%R14B %R15B %R12D %R13D %R14D %R15D %R12W %R13W %R14W %R15W>, %RSP<imp-use>
O0 didn't optimize away the usage with no side effects, so it produces the
assembly:
boo: # @boo
# BB#0:
call foo
nop
add rsp, 40
ret
O2 recognizes that the ret and rsp adjustment can move straight into foo()
which then does all of the things boo would have done if it had locals that
were used or parameters. The
boo: # @boo
# BB#0:
jmp foo # TAILCALL
It's also related to why you see both sp and rsp being marked as
modified. They technically are, but since one is a subregister it doesn't
need to be explicitly marked. Here's an O0 example of how bad O0 generated
code can end up. Note that there aren't any uses of the return from foo,
and it doesn't have side effects:
C file:
int foo(long x, long y, long z)
{
int retVal = x * y + z;
int* unused = &retVal;
return retVal;
}
void boo()
{
int x = 1;
int* y = &x;
int z = *y;
foo(x, *y, z);
}
-O0 version
=============================================================
foo: # @foo
.Lcfi0:
.seh_proc foo
# BB#0:
sub rsp, 24
.Lcfi1:
.seh_stackalloc 24
.Lcfi2:
.seh_endprologue
mov dword ptr [rsp + 8], r8d
mov dword ptr [rsp + 4], edx
mov dword ptr [rsp + 12], ecx
imul ecx, dword ptr [rsp + 4]
add ecx, dword ptr [rsp + 8]
mov dword ptr [rsp], ecx
mov rax, rsp
mov qword ptr [rsp + 16], rax
mov eax, dword ptr [rsp]
add rsp, 24
ret
.seh_handlerdata
.text
.Lcfi3:
.seh_endproc
.def boo;
.scl 2;
.type 32;
.endef
.globl boo
.p2align 4, 0x90
boo: # @boo
.Lcfi4:
.seh_proc boo
# BB#0:
sub rsp, 56
.Lcfi5:
.seh_stackalloc 56
.Lcfi6:
.seh_endprologue
mov dword ptr [rsp + 36], 1
lea rax, [rsp + 36]
mov qword ptr [rsp + 40], rax
mov r8d, dword ptr [rsp + 36]
mov dword ptr [rsp + 52], r8d
mov rax, qword ptr [rsp + 40]
mov edx, dword ptr [rax]
mov ecx, dword ptr [rsp + 36]
call foo
nop
add rsp, 56
ret
.seh_handlerdata
.text
.Lcfi7:
.seh_endproc
===================================
-O2 version
Note. EDX is neither kill or def here because it always has the same value
as x in this case, but if it didn't it would still get passed in by calling
convention.
foo: # @foo
# BB#0:
# kill: %R8D<def> %R8D<kill>
%R8<def>
# kill: %ECX<def> %ECX<kill>
%RCX<def>
imul ecx, edx
lea eax, [rcx + r8]
ret
.def boo;
.scl 2;
.type 32;
.endef
.globl boo
.p2align 4, 0x90
boo: # @boo
# BB#0:
ret
The only reason the body of foo exists at all is because the optimizer
can't be certain that another function won't call it and expect to get the
address of the local. It does know that boo() does nothing with the value,
doesn't return anything, and thus doesn't need to call the function. SO
basically the short version of all that is that O0 accepts the code at
face value and does things that aren't necesssary because it doesn't have
the analysis it needs to remove them. It also produces things like the
following sequence:
mov dword ptr [rsp], ecx
mov rax, rsp
mov qword ptr [rsp + 16], rax
mov eax, dword ptr [rsp]
which is due to an old C standard item that states that non ptr / ref input
parameters may be used as temporaries. It calculated the local retVal into
ecx, had to store it in the last slot because there was nothing telling it
it wouldn't be used later, then stored the pointer to itself (esp) at
[esp], which was never used.
Apologies if that was a simple example, but I like using it to show people
how much optimizing compilers do. I've been able to use a similar
description to teach a couple of people why optimizations were needed.
Back to your question the implicit / imp-def / dead / etc you're seeing are
just artifacts of all that clang knows when you disable its capabilities.
They would normally be used in passes later to produce the more optimal
form.
It takes getting used to the syntax but it makes sense.
Cheers,
Gordon Keiser
Software Development Engineer, Supposedly
On Mon, Feb 5, 2018 at 11:14 PM, Bhatu via llvm-dev <llvm-dev at lists.llvm.org
> wrote:
> Hi,
>
> My understanding of a "dead" register is a def that is never used. However,
> when I dump the MI after reg alloc on a simple program I see the following
> sequence:
>
> ADJCALLSTACKDOWN64 0, 0, 0, *implicit-def dead %rsp*, implicit-def dead
> %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp
> CALL64pcrel32 @foo, <regmask %bh %bl %bp %bpl %bx %ebp %ebx %rbp %rbx %r12
> %r13 %r14 %r15 %r12b %r13b %r14b %r15b %r12d %r13d %r14d %r15d %r12w %r13w
> %r14w %r15w>, *implicit %rsp*, implicit %ssp, implicit-def %rsp,
> implicit-def %ssp
> ADJCALLSTACKUP64 0, 0, implicit-def dead %rsp, implicit-def dead %eflags,
> implicit-def dead %ssp, implicit %rsp, implicit %ssp
> RET 0
>
>
> The ADJCALLSTACKDOWN64 has implicit-def dead %rsp. However the next
> instruction,
> CALL64pcrel32 has an implicit use of %rsp. This would be a use of %rsp as
> defined
> in ADJCALLSTACKDOWN64 making that non-dead.
>
> So I guess my understanding of dead is incorrect. Could you please explain
> what dead means?
>
>
> For reference:
> Source file(a.c):
> void foo(void);
> void boo(){ foo(); }
>
> Commands:
> clang -S -emit-llvm -Xclang -disable-O0-optnone a.c
> llc -print-after="stack-slot-coloring" a.ll
>
> --
> Regards
> Bhatu
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180206/c4984d12/attachment.html>
More information about the llvm-dev
mailing list