aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-reduce/llvm-reduce.cpp
diff options
context:
space:
mode:
authorDawid Jurczak <dawid_jurek@vp.pl>2021-10-10 19:52:33 +0200
committerDawid Jurczak <dawid_jurek@vp.pl>2021-10-10 21:47:14 +0200
commit9e65929a8e2c9d1d6fd9cd4cefaab58420387b2f (patch)
treeea57912d748e82873553896cd25d2169a9f9b8b8 /llvm/tools/llvm-reduce/llvm-reduce.cpp
parent9c8f950a04004736bddb5093eda15f9a1c4f2eea (diff)
downloadllvm-9e65929a8e2c9d1d6fd9cd4cefaab58420387b2f.zip
llvm-9e65929a8e2c9d1d6fd9cd4cefaab58420387b2f.tar.gz
llvm-9e65929a8e2c9d1d6fd9cd4cefaab58420387b2f.tar.bz2
[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
Diffstat (limited to 'llvm/tools/llvm-reduce/llvm-reduce.cpp')
0 files changed, 0 insertions, 0 deletions