[PATCH] D123090: MemoryBuiltins: start using properties of functions

[Augie Fackler via Phabricator via llvm-commits]

durin42 created this revision.
Herald added subscribers: okura, kuter, uenoku, JDevlieghere, hiraditya.
Herald added a reviewer: uenoku.
Herald added a project: All.
durin42 requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: sstefan1.
Herald added a reviewer: baziotis.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Prior to this change, we relied on the hard-coded list for all of the
information performed by MemoryBuiltins. With this change, we're able to
start relying on properites of functions described in attributes, which
opens the door to out-of-tree compilers being able to describe their
allocator functions to LLVM's optimizer logic without having to register
their implementation details with LLVM.

Long-term, we should be able to remove most of the hard-coded list
entries. For now we only concern ourselves with the easy cases.

The two test changes in NewGVN merit extra scrutiny: NewGVN appears to
be _extremely_ sensitive to the `inaccessiblememonly` for reasons that
are beyond me. As a result, I had-enumerated all the attributes on
allocation functions in those two tests instead of using `-inferattrs`.
I assumed that the two `-disable-simplify-libcalls` tests there no
longer are sensible since the function declaration now includes all the
relevant attributes.

Other test changes included here are the handful of cases that had some
attributes shift around a bit due to the extra stuff from inferattrs, or
similar. As best I can tell nothing important changed in tests here. One
attributor test case did require more iterations than before, but it's
in line with the other case in the file so I figured it was fine.

As of this change none of malloc, calloc, realloc, or free have any
special knowledge left in MemoryBuiltins.cpp, which means this is the
point when we should have enough logic wired up here to support the Rust
use case without any special knowledge in LLVM. I intend to finish
wiring up additional bits in clang for the C++ side as well, as
follow-up patches that should hopefully be slightly easier to review.

Depends on D123089 <https://reviews.llvm.org/D123089>


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123090

Files:
  llvm/lib/Analysis/MemoryBuiltins.cpp
  llvm/lib/Transforms/Utils/BuildLibCalls.cpp
  llvm/test/Transforms/Attributor/assumes_info.ll
  llvm/test/Transforms/Attributor/heap_to_stack.ll
  llvm/test/Transforms/Attributor/noalias.ll
  llvm/test/Transforms/Attributor/value-simplify-pointer-info.ll
  llvm/test/Transforms/NewGVN/calloc-load-removal.ll
  llvm/test/Transforms/NewGVN/malloc-load-removal.ll

STAMPS
actor(@durin42) application(Differential) author(@durin42) herald(H225) herald(H265) herald(H343) herald(H428) herald(H462) herald(H529) herald(H572) herald(H576) herald(H615) herald(H624) herald(H640) herald(H644) herald(H678) herald(H864) monogram(D123090) object-type(DREV) phid(PHID-DREV-6fqozkafcrr7c3ggvp7i) reviewer(@baziotis) reviewer(@jdoerfert) reviewer(@sstefan1) reviewer(@uenoku) revision-repository(rG) revision-status(needs-review) subscriber(@hiraditya) subscriber(@JDevlieghere) subscriber(@kuter) subscriber(@llvm-commits) subscriber(@okura) subscriber(@uenoku) tag(#all) tag(#llvm) via(conduit)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D123090.420329.patch
Type: text/x-patch
Size: 246866 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220404/69a1c81a/attachment-0001.bin>