[PATCH] D110021: [DSE] Re-enable calloc transformation with extra care (PR25892)

[Dawid Jurczak via Phabricator via llvm-commits]

yurai007 created this revision.
yurai007 added reviewers: xbolva00, nikic, asbirlea, spatel, lebedev.ri, eugenis, alexfh, MaskRay.
Herald added a subscriber: hiraditya.
yurai007 requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Transformation from malloc+memset to calloc is always correct and in many situations
it brings significant observable benefits in terms of execution speed and memory consumption [1][2].
Unfortunately there are cases when producing calloc cause performance drops [3].
As discussed here: https://reviews.llvm.org/D103009 it's possible to differentiate between those 2 scenarios.
If optimizer is able to prove that after malloc call it's _very_ likely to reach memset branch then after
calloc emission we shouldn't observe any performance hits. Therefore finding "null pointer check" pattern
before memset basic block sounds like good justification for performing transformation.
Also that method was already suggested by GCC folks [4]. Main reason for change is that for now
to be safe we check for post dominance relation which is way too conservative approach making transformation
"almost" disabled in practice. This patch tends to enable transformation again but with extra care.

[1] https://stackoverflow.com/questions/2688466/why-mallocmemset-is-slower-than-calloc
[2] https://vorpus.org/blog/why-does-calloc-exist/
[3] http://smalldatum.blogspot.com/2017/11/a-new-optimization-in-gcc-5x-and-mysql.html
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110021

Files:
  llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp
  llvm/test/Transforms/DeadStoreElimination/noop-stores.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D110021.373403.patch
Type: text/x-patch
Size: 7059 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210918/9b6b1852/attachment.bin>