[all-commits] [llvm/llvm-project] 9e6592: [DSE] Re-enable calloc transformation with extra c...

[yurai007 via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9e65929a8e2c9d1d6fd9cd4cefaab58420387b2f
      https://github.com/llvm/llvm-project/commit/9e65929a8e2c9d1d6fd9cd4cefaab58420387b2f
  Author: Dawid Jurczak <dawid_jurek at vp.pl>
  Date:   2021-10-10 (Sun, 10 Oct 2021)

  Changed paths:
    M llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp
    M llvm/test/Transforms/DeadStoreElimination/noop-stores.ll

  Log Message:
  -----------
  [DSE] Re-enable calloc transformation with extra care (PR25892)

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

Differential Revision: https://reviews.llvm.org/D110021