This patch uses the "setting changed" callback to clear previously
cached stack frames when
`target.process.disable-language-runtime-unwindplans` is changed. This
is necessary so that changing the setting followed by a `backtrace`
command produces an accurate backtrace.
With this, a user can create a custom command like below in order to
quickly inspect a backtrace created without language plugins.
```
debugger.HandleCommand("settings set target.process.disable-language-runtime-unwindplans true")
debugger.HandleCommand("bt " + command)
debugger.HandleCommand("settings set target.process.disable-language-runtime-unwindplans false")
```
In the future, we may consider implementing this as an option to
`backtrace`. Currently, this process setting is the only way of
affecting the unwinder, and changing the process setting as part of the
backtrace implementation doesn't feel right.
There are no upstream users of this flag, so we cannot write a test for
it here.
CWD is queried in clang driver and passed to clang cc1 via flags when
needed. Respect the cc1 flags and do not repeated checking current
working directory in CodeGen.
Previously, the `sycl_kernel_entry_point` attribute could be specified
using either the GNU or C++11 spelling styles. Future SYCL attributes
are expected to support only the C++11 spelling style, so support for
the GNU style is being removed.
In order to ensure consistent presentation of the attribute in
diagnostic messages, diagnostics specific to this attribute now require
the attribute to be provided as an argument. This delegates formatting
of the attribute name to the diagnostic engine.
As an additional nicety, "the" is added to some diagnostic messages so
that they read more like proper sentences.
Currently, this skips any region that is not the first region in a
block. This is because the only user of it only cares about the LiveIns
per-block. However, as named, this is supposed to compute the per-region
LiveIns.
This doesn't have any effect on scheduling / CodeGen currently (aside
from computing LiveIns for all regions) since only the per-block LiveIns
are needed. However, I'm working on something that will use this.
Intended User:
https://github.com/llvm/llvm-project/pull/149367/c62a2f127c/llvm/lib/Target/AMDGPU/GCNSchedStrategy.cpp (L1351)
This fixes a number of warnings in release builds due to variables that
were only being used in asserts. Some of these variables will later be
used in non-debug code, but for now they are unused in release builds.
This fixes a use-after-free in SymbolFileCTF. Previously, we would
remove the underlying CTF type as soon as we resolved it. However, it's
possible that we're still holding onto the CTF type while we're parsing
a dependent type, like a modifier, resulting in a use-after-free. This
patch addresses the issue by delaying the removal of the CTF type until
the type is fully resolved.
I have a XNU kernel binary that reproduces the issue and confirmed that
this solves the memory issue using ASan. However I haven't been able to
craft types by hand that reproduce this issue for a test case.
rdar://156660866
Reverts the [revert](https://github.com/llvm/llvm-project/pull/151424)
and fixed some typos.
Original PR description:
Second attempt to fix
https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434/29?u=alx32
(First attempt: https://github.com/llvm/llvm-project/pull/143656)
Context: the sequence offset to row index we parsed may not be complete.
And we need to add manual matching to it.
https://github.com/llvm/llvm-project/pull/143656 attempts to do trivial
1:1 matching, however, sometimes they don't line up perfectly, as shown
below:
// While SeqOffToOrigRow parsed from CU could be the ground truth,
// e.g.
//
// SeqOff Row
// 0x08 9
// 0x14 15
//
// The StmtAttrs and SeqStartRows may not match perfectly, e.g.
//
// StmtAttrs SeqStartRows
// 0x04 3
// 0x08 5
// 0x10 9
// 0x12 11
// 0x14 15
//
// In this case, we don't want to assign 5 to 0x08, since we know 0x08
// maps to 9. If we do a dummy 1:1 mapping 0x10 will be mapped to 9
// which is incorrect. The expected behavior is ignore 5, realign the
// table based on the result from the line table:
//
// StmtAttrs SeqStartRows
// 0x04 3
// -- 5
// 0x08 9 <- LineTableMapping ground truth
// 0x10 11
// 0x12 --
// 0x14 15 <- LineTableMapping ground truth
In this case, we need to use the mapping we read from the line table as
a ground truth and organize them properly to prevent duplicated
offset/missing offset.
Test:
Updated the test case
---------
Signed-off-by: Peter Rong <PeterRong@meta.com>
Co-authored-by: Ellis Hoag <ellis.sparky.hoag@gmail.com>
Collect the necessary information for constructing the call graph
section, and emit to .callgraph section of the binary.
MD5 hash of the callee_type metadata string is used as the numerical
type id emitted.
Reviewers: ilovepi
Reviewed By: ilovepi
Pull Request: https://github.com/llvm/llvm-project/pull/87576
You cannot use a NamedTempFile with an external process because it may
not be flushed to disk. The safest and most portable approach is to
close the file, call the other process and then unlink the file
manually.
Presumably this works fine on Linux, but it fails on Darwin when
targeting remote-linux.
See https://bugs.python.org/issue29573
Adjust the unrolling preferences to unroll hand-vectorized code, as well
as the scalar remainder of a vectorized loop. Inspired by a similar
effort in AArch64: see #147420 and #151164.
See the related issue. We want to set up a build bot where `opt` runs with `-enable-profcheck`, which inserts `MD_prof` before running the rest of the pipeline requested from `opt`, and then validates resulting profile information (more info in the RFC linked by the aforementioned issue)
In that setup, we will also ignore `FileCheck`: while the profile info inserted is, currently, equivalent to the profile info a pass would observe via `BranchProbabilityInfo`/`BlockFrequencyInfo`, (1) we may want to change that, and (2) some tests are quite sensitive to the output IR, and break if, for instance, extra metadata is present (which it would be due to `-enable-profcheck`). Since we're just interested in profile consistency on the upcoming bot, ignoring `FileCheck` is simpler and sufficient. However, this has the effect of passing XFAIL tests. Rather than listing them all, the alternative is to just exclude XFAIL tests.
This PR adds support for that by introducing a `--exclude-xfail` option to `llvm-lit`.
Issue #147390
Recent clang (as of #148337) introduced a warning on passing unitialized
pointers to functions that take const pointers. This is entirely
spurious on this code, but this works around it to keep the bots happy.
Build failure: https://lab.llvm.org/buildbot/#/builders/168/builds/14779
This commit addresses a seemingly unintentional return type of the ilogb
overload taking a double. Currently it returns double, while it is
supposed to return int.
The return types seems to be covered by libcxx/test/std/numerics/c.math/cmath.pass.cpp,
but the issue would only show up if we tested with a libc that doesn't
provide the ilogb(double) overload, which we don't.
The ultimate goal is to replace the return types of all the `DWARFIndex`
callbacks to `IterationAction`. To reduce the blast radius and do this
incrementally I'm doing this for `GetFunctions` only here. I added a
`IterationActionAdaptor` helper (that will ultimately get removed once
all APIs have been migrated) to avoid having to change too many other
APIs that `GetFunctions` interacts with.
Libc++ hardening went through several iterations, sometimes within a
single release. However, some folks in the wild have picked up these
macros that were either public at some point or that were used
temporarily on `main`, and unfortunately those are now ignored.
This can lead to some users thinking they enable hardening when in
reality they don't, which is a pretty big deal. This patch simply checks
various old hardening-related macros and ensures that they are not set,
which will catch such misuse.
The folder `shape_cast(splat constant) -> splat constant` was first
introduced
[here](36480657d8 (diff-484cea976e0c96459027c951733bf2d22d34c5a0c0de6f577069870ef4588983R2600))
(Nov 2020). In that commit there is a comment to _Only handle splat for
now_. Based on that I assume the intention was to, at a later time,
support a general `shape_cast(constant) -> constant` folder. That is
what this PR does
One minor downside: It is possible with this folder end up with, instead
of 1 large constant and 1 shape_cast, 2 large constants:
```mlir
func.func @foo() -> (vector<4xi32>, vector<2x2xi32>) {
%cst = arith.constant dense<[1, 2, 3, 4]> : vector<4xi32> # 'large' constant 1
%0 = vector.shape_cast %cst : vector<4xi32> to vector<2x2xi32>
return %cst, %0 : vector<4xi32>, vector<2x2xi32>
}
```
gets folded with this new folder to
```mlir
func.func @foo() -> (vector<4xi32>, vector<2x2xi32>) {
%cst = arith.constant dense<[1, 2, 3, 4]> : vector<4xi32> # 'large' constant 1
%cst_0 = arith.constant dense<[[1, 2], [3, 4]]> : vector<2x2xi32> # 'large' constant 2
return %cst, %cst_0 : vector<4xi32>, vector<2x2xi32>
}
```
Notes on the above case:
1) This only effects the textual IR, the actual values share the same
context storage (I've verified this by checking pointer values in the
`DenseIntOrFPElementsAttrStorage`
[constructor](da5c442550/mlir/lib/IR/AttributeDetail.h (L59)))
so no compile-time memory overhead to this folding. At the LLVM
IR level the constant is shared, too.
2) This only happens when the pre-folded constant cannot be dead code
eliminated (i.e. when it has 2+ uses) which I don't think is common.
Handles clang::DiagnosticsEngine and clang::DiagnosticIDs.
For DiagnosticIDs, this mostly migrates from `new DiagnosticIDs` to
convenience method `DiagnosticIDs::create()`.
Part of cleanup https://github.com/llvm/llvm-project/issues/151026
The declarations for this API are missing in older mingw-w64 headers
(versions before v12). This API is also hidden if building with MS
WinSDK if targeting versions before Windows 10.
Check whether THREAD_POWER_THROTTLING_CURRENT_VERSION is defined before
using this API; this constant is a #define in both WinSDK and mingw-w64.
hwasan-globals does not instrument globals with custom sections, because
existing code may use `__start_`/`__stop_` symbols to iterate over
globals in such a way which will cause hwasan assertions.
Introduce new hwasan-all-globals option, which instruments all
user-defined globals (but not those globals which are generated by the
hwasan instrumentation itself), including those with custom sections.
fixes#142442
Fix cross-compilation of test inferiors on Darwin, targeting remote
Linux. This requires specifying the target triple and using LLD for
linking.
Fixes#150806
https://github.com/llvm/llvm-project/pull/114990 allowed more aggressive
tail duplication for computed-gotos in both pre- and post-regalloc tail
duplication.
In some cases, performing tail-duplication too early can lead to worse
results, especially if we duplicate blocks with a number of phi nodes.
This is causing a ~3% performance regression in some workloads using
Python 3.12.
This patch updates TailDup to delay aggressive tail-duplication for
computed gotos to after register allocation.
This means we can keep the non-duplicated version for a bit longer
throughout the backend, which should reduce compile-time as well as
allowing a number of optimizations and simplifications to trigger before
drastically expanding the CFG.
For the case in https://github.com/llvm/llvm-project/issues/106846, I
get the same performance with and without this patch on Skylake.
PR: https://github.com/llvm/llvm-project/pull/150911
This patch adds support for lowering several float classification ops
from the Math dialect to the SPIR-V dialect.
### Highlights:
- Introduced a new `spirv.IsFinite` operation corresponding to the
SPIR-V `OpIsFinite` instruction.
- Lowered `math.isfinite`, `math.isinf`, and `math.isnan` to SPIR-V
using `CheckedElementwiseOpPattern`.
- Added corresponding tests for op definition and conversion lowering.
This addresses the discussion in:
https://github.com/llvm/llvm-project/issues/150778
---
Let me know if any additional adjustments are needed!
---------
Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>
In #112303 they were enabled for Windows dylib builds, but the condition
excluded Cygwin in that case. Their dynamic libraries work the same way,
so adjust the condition accordingly.
This fixes the plugin tests on Cygwin.
When building with -fdebug-compilation-dir/-fcoverige-compilation-dir,
infer the compilation directory in clang driver, rather than try to
fallback to VFS current working directory lookup during CodeGen. This
allows compilation directory to be used as it is passed via cc1 flag and
the value can be empty to remove dependency on CWD if needed.
Reviewers: adrian-prantl, dwblaikie
Reviewed By: adrian-prantl, dwblaikie
Pull Request: https://github.com/llvm/llvm-project/pull/150112
Implements the `inferResultRanges` method from the
`InferIntRangeInterface` interface for `vector.step`. The implementation
is similar to that of arith.constant, since the exact result values are
statically known.
Signed-off-by: Max Dawkins <max.dawkins@gmail.com>
Previously, when dwim-print finds a frame variables, it returns immediately after
calling `Dump`, even if `Dump` returns an error. This is most likely to happen when
evaluating an object description, ie `po`.
This changes dwim-print to continue on to expression evaluation when `Dump`ing a
variable returns an error . This is to allow for diagnostics that match `expression`.
%T has been deprecated for about seven years since it is not unique to
each test and can thus lead to races. This patch removes uses of %T from
clang-tools-extra with the eventual goal of removing support for %T from
lit.
Commit cdc7864 has an error which would wrongly fold widening
multiplications into an even/odd widening operation.
This PR fixes it and adds tests to check scenarios which should not be
folded into an even/odd widening operation are actually not.
