Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
#
f3869a5c |
| 27-May-2021 |
Adrian Prantl <aprantl@apple.com> |
Support stripping indirectly referenced DILocations from !llvm.loop metadata
in stripDebugInfo(). This patch fixes an oversight in https://reviews.llvm.org/D96181 and also takes into account loop m
Support stripping indirectly referenced DILocations from !llvm.loop metadata
in stripDebugInfo(). This patch fixes an oversight in https://reviews.llvm.org/D96181 and also takes into account loop metadata pointing to other MDNodes that point into the debug info.
rdar://78487175
Differential Revision: https://reviews.llvm.org/D103220
show more ...
|
#
28033302 |
| 25-May-2021 |
Marco Elver <elver@google.com> |
[SanitizeCoverage] Add support for NoSanitizeCoverage function attribute
We really ought to support no_sanitize("coverage") in line with other sanitizers. This came up again in discussions on the Li
[SanitizeCoverage] Add support for NoSanitizeCoverage function attribute
We really ought to support no_sanitize("coverage") in line with other sanitizers. This came up again in discussions on the Linux-kernel mailing lists, because we currently do workarounds using objtool to remove coverage instrumentation. Since that support is only on x86, to continue support coverage instrumentation on other architectures, we must support selectively disabling coverage instrumentation via function attributes.
Unfortunately, for SanitizeCoverage, it has not been implemented as a sanitizer via fsanitize= and associated options in Sanitizers.def, but rolls its own option fsanitize-coverage. This meant that we never got "automatic" no_sanitize attribute support.
Implement no_sanitize attribute support by special-casing the string "coverage" in the NoSanitizeAttr implementation. To keep the feature as unintrusive to existing IR generation as possible, define a new negative function attribute NoSanitizeCoverage to propagate the information through to the instrumentation pass.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=49035
Reviewed By: vitalybuka, morehouse
Differential Revision: https://reviews.llvm.org/D102772
show more ...
|
Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2 |
|
#
ea0eec69 |
| 20-Jan-2021 |
Tim Northover <t.p.northover@gmail.com> |
IR+AArch64: add a "swiftasync" argument attribute.
This extends any frame record created in the function to include that parameter, passed in X22.
The new record looks like [X22, FP, LR] in memory,
IR+AArch64: add a "swiftasync" argument attribute.
This extends any frame record created in the function to include that parameter, passed in X22.
The new record looks like [X22, FP, LR] in memory, and FP is stored with 0b0001 in bits 63:60 (CodeGen assumes they are 0b0000 in normal operation). The effect of this is that tools walking the stack should expect to see one of three values there:
* 0b0000 => a normal, non-extended record with just [FP, LR] * 0b0001 => the extended record [X22, FP, LR] * 0b1111 => kernel space, and a non-extended record.
All other values are currently reserved.
If compiling for arm64e this context pointer is address-discriminated with the discriminator 0xc31a and the DB (process-specific) key.
There is also an "i8** @llvm.swift.async.context.addr()" intrinsic providing front-ends access to this slot (and forcing its creation initialized to nullptr if necessary).
show more ...
|
#
a6d2a8d6 |
| 06-Apr-2021 |
Philip Reames <listmail@philipreames.com> |
Add a subclass of IntrinsicInst for llvm.assume [nfc]
Add the subclass, update a few places which check for the intrinsic to use idiomatic dyn_cast, and update the public interface of AssumptionCach
Add a subclass of IntrinsicInst for llvm.assume [nfc]
Add the subclass, update a few places which check for the intrinsic to use idiomatic dyn_cast, and update the public interface of AssumptionCache to use the new class. A follow up change will do the same for the newer assumption query/bundle mechanisms.
show more ...
|
#
48f5a392 |
| 03-Mar-2021 |
Bradley Smith <bradley.smith@arm.com> |
[IR] Add vscale_range IR function attribute
This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be
[IR] Add vscale_range IR function attribute
This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable.
Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute.
Differential Revision: https://reviews.llvm.org/D98030
show more ...
|
#
3bfddc25 |
| 17-Mar-2021 |
Stephen Tozer <Stephen.Tozer@Sony.com> |
Reapply "[DebugInfo] Handle multiple variable location operands in IR"
Fixed section of code that iterated through a SmallDenseMap and added instructions in each iteration, causing non-deterministic
Reapply "[DebugInfo] Handle multiple variable location operands in IR"
Fixed section of code that iterated through a SmallDenseMap and added instructions in each iteration, causing non-deterministic code; replaced SmallDenseMap with MapVector to prevent non-determinism.
This reverts commit 01ac6d1587e8613ba4278786e8341f8b492ac941.
show more ...
|
#
01ac6d15 |
| 17-Mar-2021 |
Hans Wennborg <hans@chromium.org> |
Revert "[DebugInfo] Handle multiple variable location operands in IR"
This caused non-deterministic compiler output; see comment on the code review.
> This patch updates the various IR passes to co
Revert "[DebugInfo] Handle multiple variable location operands in IR"
This caused non-deterministic compiler output; see comment on the code review.
> This patch updates the various IR passes to correctly handle dbg.values with a > DIArgList location. This patch does not actually allow DIArgLists to be produced > by salvageDebugInfo, and it does not affect any pass after codegen-prepare. > Other than that, it should cover every IR pass. > > Most of the changes simply extend code that operated on a single debug value to > operate on the list of debug values in the style of any_of, all_of, for_each, > etc. Instances of setOperand(0, ...) have been replaced with with > replaceVariableLocationOp, which takes the value that is being replaced as an > additional argument. In places where this value isn't readily available, we have > to track the old value through to the point where it gets replaced. > > Differential Revision: https://reviews.llvm.org/D88232
This reverts commit df69c69427dea7f5b3b3a4d4564bc77b0926ec88.
show more ...
|
Revision tags: llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6 |
|
#
df69c694 |
| 30-Sep-2020 |
gbtozers <stephen.tozer@sony.com> |
[DebugInfo] Handle multiple variable location operands in IR
This patch updates the various IR passes to correctly handle dbg.values with a DIArgList location. This patch does not actually allow DIA
[DebugInfo] Handle multiple variable location operands in IR
This patch updates the various IR passes to correctly handle dbg.values with a DIArgList location. This patch does not actually allow DIArgLists to be produced by salvageDebugInfo, and it does not affect any pass after codegen-prepare. Other than that, it should cover every IR pass.
Most of the changes simply extend code that operated on a single debug value to operate on the list of debug values in the style of any_of, all_of, for_each, etc. Instances of setOperand(0, ...) have been replaced with with replaceVariableLocationOp, which takes the value that is being replaced as an additional argument. In places where this value isn't readily available, we have to track the old value through to the point where it gets replaced.
Differential Revision: https://reviews.llvm.org/D88232
show more ...
|
#
e5d958c4 |
| 30-Sep-2020 |
gbtozers <stephen.tozer@sony.com> |
[DebugInfo] Support DIArgList in DbgVariableIntrinsic
This patch updates DbgVariableIntrinsics to support use of a DIArgList for the location operand, resulting in a significant change to its interf
[DebugInfo] Support DIArgList in DbgVariableIntrinsic
This patch updates DbgVariableIntrinsics to support use of a DIArgList for the location operand, resulting in a significant change to its interface. This patch does not update all IR passes to support multiple location operands in a dbg.value; the only change is to update the DbgVariableIntrinsic interface and its uses. All code outside of the intrinsic classes assumes that an intrinsic will always have exactly one location operand; they will still support DIArgLists, but only if they contain exactly one Value.
Among other changes, the setOperand and setArgOperand functions in DbgVariableIntrinsic have been made private. This is to prevent code from setting the operands of these intrinsics directly, which could easily result in incorrect/invalid operands being set. This does not prevent these functions from being called on a debug intrinsic at all, as they can still be called on any CallInst pointer; it is assumed that any code directly setting the operands on a generic call instruction is doing so safely. The intention for making these functions private is to prevent DIArgLists from being overwritten by code that's naively trying to replace one of the Values it points to, and also to fail fast if a DbgVariableIntrinsic is updated to use a DIArgList without a valid corresponding DIExpression.
show more ...
|
#
1d4a2f37 |
| 27-Feb-2021 |
Kazu Hirata <kazu@google.com> |
[Transforms/Utils] Use range-based for loops (NFC)
|
#
606aa622 |
| 11-Feb-2021 |
Michael Kruse <llvm-project@meinersbur.de> |
Revert "[AssumptionCache] Avoid dangling llvm.assume calls in the cache"
This reverts commit b7d870eae7fdadcf10d0f177faa7409c2e37d776 and the subsequent fix "[Polly] Fix build after AssumptionCache
Revert "[AssumptionCache] Avoid dangling llvm.assume calls in the cache"
This reverts commit b7d870eae7fdadcf10d0f177faa7409c2e37d776 and the subsequent fix "[Polly] Fix build after AssumptionCache change (D96168)" (commit e6810cab09fcbc87b6e5e4d226de0810e2f2ea38).
It caused indeterminism in the output, such that e.g. the polly-x86_64-linux buildbot failed accasionally.
show more ...
|
#
be23012d |
| 07-Feb-2021 |
Kazu Hirata <kazu@google.com> |
[Transforms/Utils] Use range-based for loops (NFC)
|
#
b7d870ea |
| 05-Feb-2021 |
Johannes Doerfert <johannes@jdoerfert.de> |
[AssumptionCache] Avoid dangling llvm.assume calls in the cache
PR49043 exposed a problem when it comes to RAUW llvm.assumes. While D96106 would fix it for GVNSink, it seems a more general concern.
[AssumptionCache] Avoid dangling llvm.assume calls in the cache
PR49043 exposed a problem when it comes to RAUW llvm.assumes. While D96106 would fix it for GVNSink, it seems a more general concern. To avoid future problems this patch moves away from the vector of weak reference model used in the assumption cache. Instead, we track the llvm.assume calls with a callback handle which will remove itself from the cache if the call is deleted.
Fixes PR49043.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D96168
show more ...
|
#
dc3d5453 |
| 03-Feb-2021 |
Kazu Hirata <kazu@google.com> |
[Transforms/Utils] Use range-based for loops (NFC)
|
#
8ed16361 |
| 30-Jan-2021 |
Kazu Hirata <kazu@google.com> |
[llvm] Use isa instead of dyn_cast (NFC)
|
#
bb9eb198 |
| 15-Jan-2021 |
Petr Hosek <phosek@google.com> |
Support for instrumenting only selected files or functions
This change implements support for applying profile instrumentation only to selected files or functions. The implementation uses the saniti
Support for instrumenting only selected files or functions
This change implements support for applying profile instrumentation only to selected files or functions. The implementation uses the sanitizer special case list format to select which files and functions to instrument, and relies on the new noprofile IR attribute to exclude functions from instrumentation.
Differential Revision: https://reviews.llvm.org/D94820
show more ...
|
#
1e634f39 |
| 26-Jan-2021 |
Petr Hosek <phosek@google.com> |
Revert "Support for instrumenting only selected files or functions"
This reverts commit 4edf35f11a9e20bd5df3cb47283715f0ff38b751 because the test fails on Windows bots.
|
#
4edf35f1 |
| 15-Jan-2021 |
Petr Hosek <phosek@google.com> |
Support for instrumenting only selected files or functions
This change implements support for applying profile instrumentation only to selected files or functions. The implementation uses the saniti
Support for instrumenting only selected files or functions
This change implements support for applying profile instrumentation only to selected files or functions. The implementation uses the sanitizer special case list format to select which files and functions to instrument, and relies on the new noprofile IR attribute to exclude functions from instrumentation.
Differential Revision: https://reviews.llvm.org/D94820
show more ...
|
#
8f5da41c |
| 21-Jan-2021 |
Kazu Hirata <kazu@google.com> |
[llvm] Construct SmallVector with iterator ranges (NFC)
|
#
31c0b870 |
| 18-Dec-2020 |
Rong Xu <xur@google.com> |
Fix clang-ppc64le-rhel buildbot build error
ix buildbot build error due to commit 3733463d: [IR][PGO] Add hot func attribute and use hot/cold attribute in func section
|
#
7c0e3a77 |
| 14-Dec-2020 |
Gulfem Savrun Yeniceri <gulfem@google.com> |
[clang][IR] Add support for leaf attribute
This patch adds support for leaf attribute as an optimization hint in Clang/LLVM.
Differential Revision: https://reviews.llvm.org/D90275
|
#
b5ad32ef |
| 11-Dec-2020 |
Fangrui Song <i@maskray.me> |
Migrate deprecated DebugLoc::get to DILocation::get
This migrates all LLVM (except Kaleidoscope and CodeGen/StackProtector.cpp) DebugLoc::get to DILocation::get.
The CodeGen/StackProtector.cpp usag
Migrate deprecated DebugLoc::get to DILocation::get
This migrates all LLVM (except Kaleidoscope and CodeGen/StackProtector.cpp) DebugLoc::get to DILocation::get.
The CodeGen/StackProtector.cpp usage may have a nullptr Scope and can trigger an assertion failure, so I don't migrate it.
Reviewed By: #debug-info, dblaikie
Differential Revision: https://reviews.llvm.org/D93087
show more ...
|
#
f4c6080a |
| 18-Nov-2020 |
Nick Desaulniers <ndesaulniers@google.com> |
Revert "[IR] add fn attr for no_stack_protector; prevent inlining on mismatch"
This reverts commit b7926ce6d7a83cdf70c68d82bc3389c04009b841.
Going with a simpler approach.
|
#
700d2417 |
| 03-Nov-2020 |
Giorgis Georgakoudis <georgakoudis1@llnl.gov> |
[CodeExtractor] Replace uses of extracted bitcasts in out-of-region lifetime markers
CodeExtractor handles bitcasts in the extracted region that have lifetime markers users in the outer region as ou
[CodeExtractor] Replace uses of extracted bitcasts in out-of-region lifetime markers
CodeExtractor handles bitcasts in the extracted region that have lifetime markers users in the outer region as outputs. That creates unnecessary alloca/reload instructions and extra lifetime markers. The patch identifies those cases, and replaces uses in out-of-region lifetime markers with new bitcasts in the outer region.
**Example** ``` define void @foo() { entry: %0 = alloca i32 br label %extract
extract: %1 = bitcast i32* %0 to i8* call void @llvm.lifetime.start.p0i8(i64 4, i8* %1) call void @use(i32* %0) br label %exit
exit: call void @use(i32* %0) call void @llvm.lifetime.end.p0i8(i64 4, i8* %1) ret void } ```
**Current extraction** ``` define void @foo() { entry: %.loc = alloca i8*, align 8 %0 = alloca i32, align 4 br label %codeRepl
codeRepl: ; preds = %entry %lt.cast = bitcast i8** %.loc to i8* call void @llvm.lifetime.start.p0i8(i64 -1, i8* %lt.cast) %lt.cast1 = bitcast i32* %0 to i8* call void @llvm.lifetime.start.p0i8(i64 -1, i8* %lt.cast1) call void @foo.extract(i32* %0, i8** %.loc) %.reload = load i8*, i8** %.loc, align 8 call void @llvm.lifetime.end.p0i8(i64 -1, i8* %lt.cast) br label %exit
exit: ; preds = %codeRepl call void @use(i32* %0) call void @llvm.lifetime.end.p0i8(i64 4, i8* %.reload) ret void }
define internal void @foo.extract(i32* %0, i8** %.out) { newFuncRoot: br label %extract
exit.exitStub: ; preds = %extract ret void
extract: ; preds = %newFuncRoot %1 = bitcast i32* %0 to i8* store i8* %1, i8** %.out, align 8 call void @use(i32* %0) br label %exit.exitStub } ```
**Extraction with patch** ``` define void @foo() { entry: %0 = alloca i32, align 4 br label %codeRepl
codeRepl: ; preds = %entry %lt.cast1 = bitcast i32* %0 to i8* call void @llvm.lifetime.start.p0i8(i64 -1, i8* %lt.cast1) call void @foo.extract(i32* %0) br label %exit
exit: ; preds = %codeRepl call void @use(i32* %0) %lt.cast = bitcast i32* %0 to i8* call void @llvm.lifetime.end.p0i8(i64 4, i8* %lt.cast) ret void }
define internal void @foo.extract(i32* %0) { newFuncRoot: br label %extract
exit.exitStub: ; preds = %extract ret void
extract: ; preds = %newFuncRoot %1 = bitcast i32* %0 to i8* call void @use(i32* %0) br label %exit.exitStub } ```
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D90689
show more ...
|
#
5c31b8b9 |
| 31-Oct-2020 |
Arthur Eubanks <aeubanks@google.com> |
Revert "Use uint64_t for branch weights instead of uint32_t"
This reverts commit 10f2a0d662d8d72eaac48d3e9b31ca8dc90df5a4.
More uint64_t overflows.
|