| #
c3717b68 |
| 16-Sep-2021 |
serge-sans-paille <[email protected]> |
Simplify handling of builtin with inline redefinition
(This is a recommit of 3d6f49a56995b845 that should no longer break validation since bd379915de38a9af3d65e1).
It is a common practice in glibc
Simplify handling of builtin with inline redefinition
(This is a recommit of 3d6f49a56995b845 that should no longer break validation since bd379915de38a9af3d65e1).
It is a common practice in glibc header to provide an inline redefinition of an existing function. It is especially the case for fortified function.
Clang currently has an imperfect approach to the problem, using a combination of trivially recursive function detection and noinline attribute.
Simplify the logic by suffixing these functions by `.inline` during codegen, so that they are not recognized as builtin by llvm.
After that patch, clang passes all tests from https://github.com/serge-sans-paille/fortify-test-suite
Differential Revision: https://reviews.llvm.org/D109967
show more ...
|
| #
0d76d483 |
| 28-Sep-2021 |
Kevin Athey <[email protected]> |
Revert "Simplify handling of builtin with inline redefinition"
This reverts commit 3d6f49a56995b845c40be5827ded5d1e3f692cec.
Broke bot: https://lab.llvm.org/buildbot/#/builders/5/builds/12360
|
| #
3d6f49a5 |
| 16-Sep-2021 |
serge-sans-paille <[email protected]> |
Simplify handling of builtin with inline redefinition
It is a common practice in glibc header to provide an inline redefinition of an existing function. It is especially the case for fortified funct
Simplify handling of builtin with inline redefinition
It is a common practice in glibc header to provide an inline redefinition of an existing function. It is especially the case for fortified function.
Clang currently has an imperfect approach to the problem, using a combination of trivially recursive function detection and noinline attribute.
Simplify the logic by suffixing these functions by `.inline` during codegen, so that they are not recognized as builtin by llvm.
After that patch, clang passes all tests from https://github.com/serge-sans-paille/fortify-test-suite
Differential Revision: https://reviews.llvm.org/D109967
show more ...
|
| #
e3b10525 |
| 16-Sep-2021 |
Erich Keane <[email protected]> |
Make multiversioning work with internal linkage
We previously made all multiversioning resolvers/ifuncs have weak ODR linkage in IR, since we NEED to emit the whole resolver every time we see a call
Make multiversioning work with internal linkage
We previously made all multiversioning resolvers/ifuncs have weak ODR linkage in IR, since we NEED to emit the whole resolver every time we see a call, but it is not necessarily the place where all the definitions live.
HOWEVER, when doing so, we neglected the case where the versions have internal linkage. This patch ensures we do this, so you don't get weird behavior with static functions.
show more ...
|
| #
f9bc1b3b |
| 24-Aug-2021 |
Justas Janickas <[email protected]> |
[OpenCL] Defines helper function for kernel language compatible OpenCL version
This change defines a helper function getOpenCLCompatibleVersion() inside LangOptions class. The function contains mapp
[OpenCL] Defines helper function for kernel language compatible OpenCL version
This change defines a helper function getOpenCLCompatibleVersion() inside LangOptions class. The function contains mapping between C++ for OpenCL versions and their corresponding compatible OpenCL versions. This mapping function should be updated each time a new C++ for OpenCL language version is introduced. The helper function is expected to simplify conditions on OpenCL C and C++ for OpenCL versions inside compiler code.
Code refactoring performed.
Differential Revision: https://reviews.llvm.org/D108693
show more ...
|
| #
1724a164 |
| 30-Aug-2021 |
Andrei Elovikov <[email protected]> |
[NFC][clang] Move IR-independent parts of target MV support to X86TargetParser.cpp
...that is located under llvm/lib/Support/.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.o
[NFC][clang] Move IR-independent parts of target MV support to X86TargetParser.cpp
...that is located under llvm/lib/Support/.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D108423
show more ...
|
| #
7cab90a7 |
| 26-Aug-2021 |
Alex Richardson <[email protected]> |
Fix __attribute__((annotate("")) with non-zero globals AS
The existing code attempting to bitcast from a value in the default globals AS to i8 addrspace(0)* was triggering an assertion failure in ou
Fix __attribute__((annotate("")) with non-zero globals AS
The existing code attempting to bitcast from a value in the default globals AS to i8 addrspace(0)* was triggering an assertion failure in our downstream fork. I found this while compiling poppler for CHERI-RISC-V (we use AS200 for all globals). The test case uses AMDGPU since that is one of the in-tree targets with a non-zero default globals address space. The new test previously triggered a "Invalid constantexpr bitcast!" assertion and now correctly generates code with addrspace(1) pointers.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D105972
show more ...
|
| #
846e562d |
| 25-Aug-2021 |
Nick Desaulniers <[email protected]> |
[Clang] add support for error+warning fn attrs
Add support for the GNU C style __attribute__((error(""))) and __attribute__((warning(""))). These attributes are meant to be put on declarations of fu
[Clang] add support for error+warning fn attrs
Add support for the GNU C style __attribute__((error(""))) and __attribute__((warning(""))). These attributes are meant to be put on declarations of functions whom should not be called.
They are frequently used to provide compile time diagnostics similar to _Static_assert, but which may rely on non-ICE conditions (ie. relying on compiler optimizations). This is also similar to diagnose_if function attribute, but can diagnose after optimizations have been run.
While users may instead simply call undefined functions in such cases to get a linkage failure from the linker, these provide a much more ergonomic and actionable diagnostic to users and do so at compile time rather than at link time. Users instead may be able use inline asm .err directives.
These are used throughout the Linux kernel in its implementation of BUILD_BUG and BUILD_BUG_ON macros. These macros generally cannot be converted to use _Static_assert because many of the parameters are not ICEs. The Linux kernel still needs to be modified to make use of these when building with Clang; I have a patch that does so I will send once this feature is landed.
To do so, we create a new IR level Function attribute, "dontcall" (both error and warning boil down to one IR Fn Attr). Then, similar to calls to inline asm, we attach a !srcloc Metadata node to call sites of such attributed callees.
The backend diagnoses these during instruction selection, while we still know that a call is a call (vs say a JMP that's a tail call) in an arch agnostic manner.
The frontend then reconstructs the SourceLocation from that Metadata, and determines whether to emit an error or warning based on the callee's attribute.
Link: https://bugs.llvm.org/show_bug.cgi?id=16428 Link: https://github.com/ClangBuiltLinux/linux/issues/1173
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D106030
show more ...
|
| #
ea08c4cd |
| 20-Aug-2021 |
Jonas Hahnfeld <[email protected]> |
[CUDA] Fix static device variables with -fgpu-rdc
NVPTX does not allow dots in the identifier, so ptxas errors out with fatal : Parsing error near '.static': syntax error because it parses .sta
[CUDA] Fix static device variables with -fgpu-rdc
NVPTX does not allow dots in the identifier, so ptxas errors out with fatal : Parsing error near '.static': syntax error because it parses .static as a directive. Avoid this problem by using two underscores, similar to what OpenMP does for outlined functions.
Differential Revision: https://reviews.llvm.org/D108456
show more ...
|
| #
8da70fed |
| 04-Aug-2021 |
Andy Wingo <[email protected]> |
[clang][NFC] Tighten up code for GetGlobalVarAddressSpace
The LangAS local is only used in the OpenCL case; move its decl inwards.
Differential Revision: https://reviews.llvm.org/D108449
|
| #
d3d4d985 |
| 04-Aug-2021 |
Andy Wingo <[email protected]> |
[clang][NFC] GetOrCreateLLVMGlobal takes LangAS
Pass a LangAS instead of a target address space to GetOrCreateLLVMGlobal, to remove a place where the frontend assumes that target address space 0 is
[clang][NFC] GetOrCreateLLVMGlobal takes LangAS
Pass a LangAS instead of a target address space to GetOrCreateLLVMGlobal, to remove a place where the frontend assumes that target address space 0 is special.
Differential Revision: https://reviews.llvm.org/D108445
show more ...
|
| #
de0ae9e8 |
| 17-Aug-2021 |
Arthur Eubanks <[email protected]> |
[NFC] Cleanup more AttributeList::addAttribute()
|
| #
ad727ab7 |
| 17-Aug-2021 |
Arthur Eubanks <[email protected]> |
[NFC] Migrate some callers away from Function/AttributeLists methods that take an index
These methods can be confusing.
|
| #
46cf8253 |
| 16-Aug-2021 |
Arthur Eubanks <[email protected]> |
[NFC] Replace Function handling of attributes with less confusing calls
To avoid magic constants and confusing indexes.
|
| #
8e9ffa1d |
| 13-Aug-2021 |
Arthur Eubanks <[email protected]> |
[NFC] Cleanup callers of AttributeList::hasAttributes()
AttributeList::hasAttributes() is confusing, use clearer methods like hasFnAttrs().
|
| #
80ea2bb5 |
| 13-Aug-2021 |
Arthur Eubanks <[email protected]> |
[NFC] Rename AttributeList::getParam/Ret/FnAttributes() -> get*Attributes()
This is more consistent with similar methods.
|
| #
6ec36d18 |
| 08-Aug-2021 |
Michael Liao <[email protected]> |
[cuda] Mark builtin texture/surface reference variable as 'externally_initialized'.
- They need to be preserved even if there's no reference within the device code as the host code may need to ini
[cuda] Mark builtin texture/surface reference variable as 'externally_initialized'.
- They need to be preserved even if there's no reference within the device code as the host code may need to initialize them based on the application logic.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D107718
show more ...
|
| #
7df405e0 |
| 04-Aug-2021 |
Pavel Asyutchenko <[email protected]> |
Apply -fmacro-prefix-map to __builtin_FILE()
This matches the behavior of GCC. Patch does not change remapping logic itself, so adding one simple smoke test should be enough.
Reviewed By: MaskRay
Apply -fmacro-prefix-map to __builtin_FILE()
This matches the behavior of GCC. Patch does not change remapping logic itself, so adding one simple smoke test should be enough.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D107393
show more ...
|
| #
44dbbe61 |
| 19-Jul-2021 |
Yaxun (Sam) Liu <[email protected]> |
[HIP] Preserve ASAN bitcode library functions
Address sanitizer passes may generate call of ASAN bitcode library functions after bitcode linking in lld, therefore lld cannot add those symbols since
[HIP] Preserve ASAN bitcode library functions
Address sanitizer passes may generate call of ASAN bitcode library functions after bitcode linking in lld, therefore lld cannot add those symbols since it does not know they will be used later.
To solve this issue, clang emits a reference to a bicode library function which calls all ASAN functions which need to be preserved. This basically force all ASAN functions to be linked in.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D106315
show more ...
|
| #
9ce02ea8 |
| 24-Jun-2021 |
Joseph Huber <[email protected]> |
[OpenMP] Add Module metadata for OpenMP compilation
This patch adds a module level metadata flag indicating that the module was compiled with the `-fopenmp` flag. This will make it easier for passes
[OpenMP] Add Module metadata for OpenMP compilation
This patch adds a module level metadata flag indicating that the module was compiled with the `-fopenmp` flag. This will make it easier for passes like OpenMPOpt to determine if it should be run.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D102361
show more ...
|
| #
8ace1213 |
| 21-Jun-2021 |
Nick Desaulniers <[email protected]> |
[IR] convert warn-stack-size from module flag to fn attr
Otherwise, this causes issues when building with LTO for object files that use different values.
Link: https://github.com/ClangBuiltLinux/li
[IR] convert warn-stack-size from module flag to fn attr
Otherwise, this causes issues when building with LTO for object files that use different values.
Link: https://github.com/ClangBuiltLinux/linux/issues/1395
Reviewed By: dblaikie, MaskRay
Differential Revision: https://reviews.llvm.org/D104342
show more ...
|
| #
61cdaf66 |
| 11-Jun-2021 |
Simon Pilgrim <[email protected]> |
[ADT] Remove APInt/APSInt toString() std::string variants
<string> is currently the highest impact header in a clang+llvm build:
https://commondatastorage.googleapis.com/chromium-browser-clang/llvm
[ADT] Remove APInt/APSInt toString() std::string variants
<string> is currently the highest impact header in a clang+llvm build:
https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html
One of the most common places this is being included is the APInt.h header, which needs it for an old toString() implementation that returns std::string - an inefficient method compared to the SmallString versions that it actually wraps.
This patch replaces these APInt/APSInt methods with a pair of llvm::toString() helpers inside StringExtras.h, adjusts users accordingly and removes the <string> from APInt.h - I was hoping that more of these users could be converted to use the SmallString methods, but it appears that most end up creating a std::string anyhow. I avoided trying to use the raw_ostream << operators as well as I didn't want to lose having the integer radix explicit in the code.
Differential Revision: https://reviews.llvm.org/D103888
show more ...
|
| #
fc018ebb |
| 10-Jun-2021 |
Nick Desaulniers <[email protected]> |
[IR] make -warn-frame-size into a module attr
-Wframe-larger-than= is an interesting warning; we can't know the frame size until PrologueEpilogueInsertion (PEI); very late in the compilation pipelin
[IR] make -warn-frame-size into a module attr
-Wframe-larger-than= is an interesting warning; we can't know the frame size until PrologueEpilogueInsertion (PEI); very late in the compilation pipeline.
-Wframe-larger-than= was propagated through CC1 as an -mllvm flag, then was a cl::opt in LLVM's PEI pass; this meant it was dropped during LTO and needed to be re-specified via -plugin-opt.
Instead, make it part of the IR proper as a module level attribute, similar to D103048. Introduce -fwarn-stack-size CC1 option.
Reviewed By: rsmith, qcolombet
Differential Revision: https://reviews.llvm.org/D103928
show more ...
|
| #
b2d0c16e |
| 05-May-2021 |
Nathan Sidwell <[email protected]> |
[clang] p1099 using enum part 2
This implements the 'using enum maybe-qualified-enum-tag ;' part of 1099. It introduces a new 'UsingEnumDecl', subclassed from 'BaseUsingDecl'. Much of the diff is th
[clang] p1099 using enum part 2
This implements the 'using enum maybe-qualified-enum-tag ;' part of 1099. It introduces a new 'UsingEnumDecl', subclassed from 'BaseUsingDecl'. Much of the diff is the boilerplate needed to get the new class set up.
There is one case where we accept ill-formed, but I believe this is merely an extended case of an existing bug, so consider it orthogonal. AFAICT in class-scope the c++20 rule is that no 2 using decls can bring in the same target decl ([namespace.udecl]/8). But we already accept:
struct A { enum { a }; }; struct B : A { using A::a; }; struct C : B { using A::a; using B::a; }; // same enumerator
this patch permits mixtures of 'using enum Bob;' and 'using Bob::member;' in the same way.
Differential Revision: https://reviews.llvm.org/D102241
show more ...
|
| #
3787ee45 |
| 08-Jun-2021 |
Nick Desaulniers <[email protected]> |
reland [IR] make -stack-alignment= into a module attr
Relands commit 433c8d950cb3a1fa0977355ce0367e8c763a3f13 with fixes for MIPS.
Similar to D102742, specifying the stack alignment via CodegenOpts
reland [IR] make -stack-alignment= into a module attr
Relands commit 433c8d950cb3a1fa0977355ce0367e8c763a3f13 with fixes for MIPS.
Similar to D102742, specifying the stack alignment via CodegenOpts means that this flag gets dropped during LTO, unless the command line is re-specified as a plugin opt. Instead, encode this information as a module level attribute so that we don't have to expose this llvm internal flag when linking the Linux kernel with LTO.
Looks like external dependencies might need a fix: * https://github.com/llvm-hs/llvm-hs/issues/345 * https://github.com/halide/Halide/issues/6079
Link: https://github.com/ClangBuiltLinux/linux/issues/1377
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D103048
show more ...
|