|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
8dfaecc4 |
| 23-Jul-2022 |
Argyrios Kyrtzidis <[email protected]> |
[CGDebugInfo] Access the current working directory from the `VFS`
...instead of calling `llvm::sys::fs::current_path()` directly.
Differential Revision: https://reviews.llvm.org/D130443
|
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5 |
|
| #
858e6273 |
| 31-May-2022 |
Nikita Popov <[email protected]> |
[Clang] Always set opaque pointers mode
Always set the opaque pointers mode, to make sure that -no-opaque-pointers continues working when the default on the LLVM side is flipped.
|
|
Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
bac6cd5b |
| 01-Apr-2022 |
Paul Kirth <[email protected]> |
[misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata.
New checks
[misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata.
New checks rely on 2 invariants:
1) For frontend instrumentation, MD_prof branch_weights will always be populated before llvm.expect intrinsics are lowered.
2) for IR and sample profiling, llvm.expect intrinsics will always be lowered before branch_weights are populated from the IR profiles.
These invariants allow the checking to assume how the existing branch weights are populated depending on the profiling method used, and emit the correct diagnostics. If these invariants are ever invalidated, the MisExpect related checks would need to be updated, potentially by re-introducing MD_misexpect metadata, and ensuring it always will be transformed the same way as branch_weights in other optimization passes.
Frontend based profiling is now enabled without using LLVM Args, by introducing a new CodeGen option, and checking if the -Wmisexpect flag has been passed on the command line.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D115907
show more ...
|
| #
46cfbe56 |
| 05-Apr-2022 |
Nikita Popov <[email protected]> |
[LLVMContext] Replace enableOpaquePointers() with setOpaquePointers()
This allows both explicitly enabling and explicitly disabling opaque pointers, in anticipation of the default switching at some
[LLVMContext] Replace enableOpaquePointers() with setOpaquePointers()
This allows both explicitly enabling and explicitly disabling opaque pointers, in anticipation of the default switching at some point.
This also slightly changes the rules by allowing calls if either the opaque pointer mode has not yet been set (explicitly or implicitly) or if the value remains unchanged.
show more ...
|
| #
d69e9f9d |
| 04-Apr-2022 |
Nikita Popov <[email protected]> |
[OpaquePtrs][Clang] Add -opaque-pointers/-no-opaque-pointers cc1 options
This adds cc1 options for enabling and disabling opaque pointers on the clang side. This is not super useful now (because -ml
[OpaquePtrs][Clang] Add -opaque-pointers/-no-opaque-pointers cc1 options
This adds cc1 options for enabling and disabling opaque pointers on the clang side. This is not super useful now (because -mllvm -opaque-pointers and -Xclang -opaque-pointers have the same visible effect) but will be important once opaque pointers are enabled by default in clang. In that case, it will only be possible to disable them using the cc1 -no-opaque-pointers option.
Differential Revision: https://reviews.llvm.org/D123034
show more ...
|
| #
fc7573f2 |
| 31-Mar-2022 |
Jorge Gorbe Moya <[email protected]> |
Revert "[misexpect] Re-implement MisExpect Diagnostics"
This reverts commit 46774df307159444d65083c2fd82f8574f0ab1d9.
|
| #
46774df3 |
| 29-Mar-2022 |
Paul Kirth <[email protected]> |
[misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata.
New checks
[misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata.
New checks rely on 2 invariants:
1) For frontend instrumentation, MD_prof branch_weights will always be populated before llvm.expect intrinsics are lowered.
2) for IR and sample profiling, llvm.expect intrinsics will always be lowered before branch_weights are populated from the IR profiles.
These invariants allow the checking to assume how the existing branch weights are populated depending on the profiling method used, and emit the correct diagnostics. If these invariants are ever invalidated, the MisExpect related checks would need to be updated, potentially by re-introducing MD_misexpect metadata, and ensuring it always will be transformed the same way as branch_weights in other optimization passes.
Frontend based profiling is now enabled without using LLVM Args, by introducing a new CodeGen option, and checking if the -Wmisexpect flag has been passed on the command line.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D115907
show more ...
|
| #
90cb325a |
| 29-Mar-2022 |
Paul Kirth <[email protected]> |
Revert "[misexpect] Re-implement MisExpect Diagnostics"
This reverts commit 2add3fbd976d7b80a3a7fc14ef0deb9b1ca6beee.
|
| #
2add3fbd |
| 19-Mar-2022 |
Paul Kirth <[email protected]> |
[misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata.
New checks
[misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata.
New checks rely on 2 invariants:
1) For frontend instrumentation, MD_prof branch_weights will always be populated before llvm.expect intrinsics are lowered.
2) for IR and sample profiling, llvm.expect intrinsics will always be lowered before branch_weights are populated from the IR profiles.
These invariants allow the checking to assume how the existing branch weights are populated depending on the profiling method used, and emit the correct diagnostics. If these invariants are ever invalidated, the MisExpect related checks would need to be updated, potentially by re-introducing MD_misexpect metadata, and ensuring it always will be transformed the same way as branch_weights in other optimization passes.
Frontend based profiling is now enabled without using LLVM Args, by introducing a new CodeGen option, and checking if the -Wmisexpect flag has been passed on the command line.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D115907
show more ...
|
| #
964398cc |
| 18-Mar-2022 |
Paul Kirth <[email protected]> |
Revert "Revert "Revert "[misexpect] Re-implement MisExpect Diagnostics"""
This reverts commit 6cf560d69a222bff4af4e1d092437fd77f0f981c.
|
| #
6cf560d6 |
| 18-Mar-2022 |
Paul Kirth <[email protected]> |
Revert "Revert "[misexpect] Re-implement MisExpect Diagnostics""
I mistakenly reverted my commit, so I'm relanding it.
This reverts commit 10866a1df4a82cdc54187330c509a2d46235455d.
|
| #
10866a1d |
| 17-Mar-2022 |
Paul Kirth <[email protected]> |
Revert "[misexpect] Re-implement MisExpect Diagnostics"
This reverts commit e7749d4713a5ec886011ceb0fc821c6723061724.
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
| #
e7749d47 |
| 09-Mar-2022 |
Paul Kirth <[email protected]> |
[misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata.
New checks
[misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata.
New checks rely on 2 invariants:
1) For frontend instrumentation, MD_prof branch_weights will always be populated before llvm.expect intrinsics are lowered.
2) for IR and sample profiling, llvm.expect intrinsics will always be lowered before branch_weights are populated from the IR profiles.
These invariants allow the checking to assume how the existing branch weights are populated depending on the profiling method used, and emit the correct diagnostics. If these invariants are ever invalidated, the MisExpect related checks would need to be updated, potentially by re-introducing MD_misexpect metadata, and ensuring it always will be transformed the same way as branch_weights in other optimization passes.
Frontend based profiling is now enabled without using LLVM Args, by introducing a new CodeGen option, and checking if the -Wmisexpect flag has been passed on the command line.
Differential Revision: https://reviews.llvm.org/D115907
show more ...
|
| #
b3dae59b |
| 09-Mar-2022 |
Ryan Senanayake <[email protected]> |
[clang] Fix CodeGenAction for LLVM IR MemBuffers
Replaces use of getCurrentFile with getCurrentFileOrBufferName in CodeGenAction. This avoids an assertion error or an incorrect name chosen for the o
[clang] Fix CodeGenAction for LLVM IR MemBuffers
Replaces use of getCurrentFile with getCurrentFileOrBufferName in CodeGenAction. This avoids an assertion error or an incorrect name chosen for the output file when assertions are disabled. This error previously occurred when the FrontendInputFile was a MemoryBuffer instead of a file.
Reviewed By: jlebar
Differential Revision: https://reviews.llvm.org/D121259
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
551b1774 |
| 03-Dec-2021 |
Joseph Huber <[email protected]> |
[OpenMP] Add a flag for embedding a file into the module
This patch adds support for a flag `-fembed-offload-binary` to embed a file as an ELF section in the output by placing it in a global variabl
[OpenMP] Add a flag for embedding a file into the module
This patch adds support for a flag `-fembed-offload-binary` to embed a file as an ELF section in the output by placing it in a global variable. This can be used to bundle offloading files with the host binary so it can be accessed by the linker. The section is named using the `-fembed-offload-section` option.
Depends on D116541
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D116542
show more ...
|
| #
2d303e67 |
| 25-Dec-2021 |
Kazu Hirata <[email protected]> |
Remove redundant return and continue statements (NFC)
Identified with readability-redundant-control-flow.
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
063c2f89 |
| 19-Oct-2021 |
Arthur Eubanks <[email protected]> |
[clang] Add option to disable -clear-ast-before-backend
Some downstream users have plugins that -clear-ast-before-backend may affect. Add an option to opt out.
Reviewed By: dblaikie
Differential R
[clang] Add option to disable -clear-ast-before-backend
Some downstream users have plugins that -clear-ast-before-backend may affect. Add an option to opt out.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D112100
show more ...
|
| #
d0a5f61c |
| 13-Oct-2021 |
Arthur Eubanks <[email protected]> |
[clang] Support -clear-ast-before-backend without -disable-free
Previously without -disable-free, -clear-ast-before-backend would crash in ~ASTContext() due to various reasons. This works around tha
[clang] Support -clear-ast-before-backend without -disable-free
Previously without -disable-free, -clear-ast-before-backend would crash in ~ASTContext() due to various reasons. This works around that by doing a lot of the cleanup ahead of the destructor so that the destructor doesn't actually do any manual cleanup if we've already cleaned up beforehand.
This actually does save a measurable amount of memory with -clear-ast-before-backend, although at an almost unnoticeable runtime cost: https://llvm-compile-time-tracker.com/compare.php?from=5d755b32f2775b9219f6d6e2feda5e1417dc993b&to=58ef1c7ad7e2ad45f9c97597905a8cf05a26258c&stat=max-rss
Previously we weren't doing any cleanup with -disable-free, so I tried measuring the impact of always doing the cleanup and didn't measure anything noticeable on llvm-compile-time-tracker.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D111767
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4 |
|
| #
6522b7cc |
| 14-Sep-2021 |
Arthur Eubanks <[email protected]> |
[clang] Add option to clear AST memory before running LLVM passes
This is to save memory for Clang compiles. Measuring building PassBuilder.cpp under /usr/bin/time, max rss goes from 0.93GB to 0.7GB
[clang] Add option to clear AST memory before running LLVM passes
This is to save memory for Clang compiles. Measuring building PassBuilder.cpp under /usr/bin/time, max rss goes from 0.93GB to 0.7GB.
This does not turn it by default yet.
I've turned on the option locally and run it over a good amount of files without any issues.
For more background, see https://lists.llvm.org/pipermail/cfe-dev/2021-September/068930.html.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D111105
show more ...
|
| #
25682868 |
| 14-Sep-2021 |
Arthur Eubanks <[email protected]> |
[clang] Don't use the AST to display backend diagnostics
We keep a map from function name to source location so we don't have to do it via looking up a source location from the AST. However, since f
[clang] Don't use the AST to display backend diagnostics
We keep a map from function name to source location so we don't have to do it via looking up a source location from the AST. However, since function names can be long, we actually use a hash of the function name as the key.
Additionally, we can't rely on Clang's printing of function names via the AST, so we just demangle the name instead.
This is necessary to implement https://lists.llvm.org/pipermail/cfe-dev/2021-September/068930.html.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D110665
show more ...
|
| #
aa53785f |
| 23-Sep-2021 |
Arthur Eubanks <[email protected]> |
Reland [clang] Rework dontcall attributes
To avoid using the AST when emitting diagnostics, split the "dontcall" attribute into "dontcall-warn" and "dontcall-error", and also add the frontend attrib
Reland [clang] Rework dontcall attributes
To avoid using the AST when emitting diagnostics, split the "dontcall" attribute into "dontcall-warn" and "dontcall-error", and also add the frontend attribute value as the LLVM attribute value. This gives us all the information to report diagnostics we need from within the IR (aside from access to the original source).
One downside is we directly use LLVM's demangler rather than using the existing Clang diagnostic pretty printing of symbols.
Previous revisions didn't properly declare the new dependencies.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D110364
show more ...
|
| #
7833d20f |
| 28-Sep-2021 |
Arthur Eubanks <[email protected]> |
Revert "[clang] Rework dontcall attributes"
This reverts commit 2943071e2ee0c7f31f34062a44d12aeb0e3a66fd.
Breaks bots
|
| #
2943071e |
| 23-Sep-2021 |
Arthur Eubanks <[email protected]> |
[clang] Rework dontcall attributes
To avoid using the AST when emitting diagnostics, split the "dontcall" attribute into "dontcall-warn" and "dontcall-error", and also add the frontend attribute val
[clang] Rework dontcall attributes
To avoid using the AST when emitting diagnostics, split the "dontcall" attribute into "dontcall-warn" and "dontcall-error", and also add the frontend attribute value as the LLVM attribute value. This gives us all the information to report diagnostics we need from within the IR (aside from access to the original source).
One downside is we directly use LLVM's demangler rather than using the existing Clang diagnostic pretty printing of symbols.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D110364
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
| #
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 ...
|
| #
1c829ce1 |
| 21-Aug-2021 |
Bob Haarman <[email protected]> |
[clang][codegen] Set CurLinkModule in CodeGenAction::ExecuteAction
CodeGenAction::ExecuteAction creates a BackendConsumer for the purpose of handling diagnostics. The BackendConsumer's DiagnosticHan
[clang][codegen] Set CurLinkModule in CodeGenAction::ExecuteAction
CodeGenAction::ExecuteAction creates a BackendConsumer for the purpose of handling diagnostics. The BackendConsumer's DiagnosticHandlerImpl method expects CurLinkModule to be set, but this did not happen on the code path that goes through ExecuteAction. This change makes it so that the BackendConsumer constructor used by ExecuteAction requires the Module to be specified and passes the appropriate module in ExecuteAction.
The change also adds a test that fails without this change and passes with it. To make the test work, the FIXME in the handling of DK_Linker diagnostics was addressed so that warnings and notes are no longer silently discarded. Since this introduces a new warning diagnostic, a flag to control it (-Wlinker-warnings) has also been added.
Reviewed By: xur
Differential Revision: https://reviews.llvm.org/D108603
show more ...
|