[llvm-dev] Dead store elimination in the backend for -ftrivial-auto-var-init

Alexander Potapenko via llvm-dev llvm-dev at lists.llvm.org
Thu Aug 1 07:21:20 PDT 2019

Hi folks,

When compiling the attached example with -ftrivial-auto-var-init=zero:

$ clang   -no-integrated-as  -mno-sse -m64 -mstack-alignment=8    -O2
-g  -o ipt.ll -c ipt.i -w -S -emit-llvm

, Clang generates an initialization memset() call for |acpar| in the IR:

    %0 = bitcast %struct.xt_action_param* %acpar to i8*, !dbg !27
    call void @llvm.memset.p0i8.i64(i8* nonnull align 8 %0, i8 0, i64
40, i1 false), !dbg !28

Clang only splits memsets into series of stores under certain
conditions, so it's hard to remove redundant stores on the IR level
(even with the recent DSE patches: https://reviews.llvm.org/D61879).
In the resulting assembly, however, the memset is lowered into a
series of MOVQ instructions (see the attached ipt.s file), of which at
least the stores to 24(%rsp) and 16(%rsp) are redundant.

Given that at MCInst level we already know if a memset is split into a
sequence of stores, can we do a better job by making the backend
delete these redundant stores for us?


Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipt.i
Type: application/octet-stream
Size: 461 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190801/b6398a44/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipt.s
Type: application/octet-stream
Size: 1880 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190801/b6398a44/attachment-0001.obj>

More information about the llvm-dev mailing list