[all-commits] [llvm/llvm-project] dccfaf: Revert "[BuildLibcalls, Attrs] Support more varian...
Richard Smith via All-commits
all-commits at lists.llvm.org
Fri Feb 12 16:38:04 PST 2021
Branch: refs/heads/release/12.x
Home: https://github.com/llvm/llvm-project
Commit: dccfafaf8cc1085724331a8427f656d7636679ba
https://github.com/llvm/llvm-project/commit/dccfafaf8cc1085724331a8427f656d7636679ba
Author: Richard Smith <richard at metafoo.co.uk>
Date: 2021-02-12 (Fri, 12 Feb 2021)
Changed paths:
M llvm/lib/Transforms/Utils/BuildLibCalls.cpp
M llvm/test/Transforms/InferFunctionAttrs/annotate.ll
Log Message:
-----------
Revert "[BuildLibcalls, Attrs] Support more variants of C++'s new, add attributes for C++'s delete"
Several of the new attributes here were incorrect, and even the ones
that are generally correct were being added even to nobuiltin calls.
This reverts commit bb3f169b59e1c8bd7fd70097532220bbd11e9967.
(cherry picked from commit 1484ad4137b5d627573672bad48b03785f8fdefd)
Commit: 97dd9224f1033b1d6313ae80047e48ff964ca77d
https://github.com/llvm/llvm-project/commit/97dd9224f1033b1d6313ae80047e48ff964ca77d
Author: Richard Smith <richard at metafoo.co.uk>
Date: 2021-02-12 (Fri, 12 Feb 2021)
Changed paths:
M llvm/lib/Transforms/Utils/BuildLibCalls.cpp
M llvm/test/Transforms/InferFunctionAttrs/annotate.ll
Log Message:
-----------
Don't infer attributes on '::operator new'.
These attributes were all incorrect or inappropriate for LLVM to infer:
- inaccessiblememonly is generally wrong; user replacement operator new
can access memory that's visible to the caller, as can a new_handler
function.
- willreturn is generally wrong; a custom new_handler is not guaranteed
to terminate.
- noalias is inappropriate: Clang has a flag to determine whether this
attribute should be present and adds it itself when appropriate.
- noundef and nonnull on the return value should be specified by the
frontend on all 'operator new' functions if we want them, not here.
In any case, inferring attributes on functions declared 'nobuiltin' (as
these are when Clang emits them) seems questionable.
(cherry picked from commit ab243efb261ba7e27f4b14e1a6fbbff15a79c0bf)
Compare: https://github.com/llvm/llvm-project/compare/a67a4346f78d...97dd9224f103
More information about the All-commits
mailing list