This allows `llvm-dwarfdump` to decode the DWARF 5 opcode
`DW_OP_implicit_pointer` (0xa0). GCC makes use of this opcode in recent
versions. LLVM contains some (unfinished) support as well. With existing
usage in the ecosystem, adding decoding support here seems reasonable.
This fixes https://github.com/llvm/llvm-project/issues/56125 and
https://github.com/vadimcn/codelldb/issues/666, as well as the
downstream issue in our binary ninja debugger:
https://github.com/Vector35/debugger/issues/535
Basically, lldb does not claim to support the `swbreak` packet so the
gdbserver would not use it. As a result, the gdbserver always sends the
unmodified program counter value which, on systems like x86, causes the
program counter to be off-by-one (or otherwise wrong). For reference,
the lldb-server always sends the modified program counter value so it
works perfectly with lldb.
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Stop-Reply-Packets.html#swbreak-stop-reason
No new code is added to add support `swbreak`, since the way lldb works
already expects the remote to have adjusted the program counter. The
change just lets the gdbserver know that lldb supports it, so that it
will send the adjusted program counter.
To test this PR, you can use lldb to connect to a gdbserver running on
e.g., Ubuntu 22.04, and see the program counter is off-by-one without
the patch. With the patch, things work as expected
This patch updates the GlobalMerge pass to be able to handle private
global variables, which is required for a follow-up PowerPC specific
GlobalMerge patch to merge internal and private globals.
A new LIT test is also added to exhibit the ability to merge private
globals.
This script can be run manually to synchronize the CSV files that we use
to track Standards Conformance with the Github issues that track our
implementation of LWG issues and papers.
`Flang :: Evaluate/fold-out_of_range.f90` currently `FAIL`s on
Linux/sparc64. This seems to be the same issue that led to disabling the
test on Solaris in 27549ee989d7e0803d41c206cf636f0b689210f1. In fact,
the generic Solaris disablement was over-eager: the test `PASS`es just
fine on Solaris/amd64.
Since the use of `REAL*10` makes the test x86-specific, this patch
actually implements that requirement.
Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`,
`amd64-pc-solaris2.11`, and `x86_64-pc-linux-gnu`.
Similar to #102156.
runOnMachineFunction() installs the Observer correctly manually.
finishPendingPhis() doesn't install into the MF, but this currently
can't cause issues because DILocationVerifier doesn't care about changed
instructions.
Switch to RAIIMFObsDelInstaller in both places for consistency.
Adds tests with scalable vectors for the Vector-To-LLVM conversion pass.
Covers the following Ops:
* vector.extractelement
* vector.extract
I have also renamed some function names from `@extract_element{}` to
`@extractelement{}` - that's to make a clearer distinction between
tests for `vector.extractelement` (tested by `@extractelement{}`) and
`vector.extract` (tested by `@extract_element{}`).
The following functions have an early exit for scalable vectors:
SelectionDAG::canCreateUndefOrPoison
SelectionDAG:isGuaranteedNotToBeUndefOrPoison
The implementations of these don't look to be sensitive to the
vector type other than some uses of demanded elts analysis that
doesn't fully support scalable types. That said the initial
calculation demands all elements and so I've followed the same
scheme as used by TargetLowering::SimplifyDemandedBits.
On 64bit targets we can promote i32 CTTZ nodes to i64 CTTZ_ZERO_UNDEF by setting the 32nd bit.
#57811 also queried about whether we should use BTS instead of MOVABS+OR to avoid a i64 immediate - I'm willing to tweak the DAGToDAG isel peephole for these cases if reviewers think it worthwhile. But most recent CPUs can actually handle MOVABS faster than BTS/C/R.......
Reapplied with missing costmodel changes - the cost tables can probably be improved in a follow up patch.
Fixes#57811
This allows adding a Clang attribute
`swift_attr("conforms_to:ModuleName.ProtocolName")` to C++ structs via
API Notes.
The Swift compiler respects this attribute when importing C++ types into
Swift by automatically declaring the C++ type as a conforming type to
the given Swift protocol.
rdar://131388824
We were using tryGetRealPathName in certain places, which resolves
symlinks (sometimes). This was resulting in discrepancies in behavior,
depending on how a file was first reached.
This path migrates all usages of tryGetRealPathName to regular getName
instead.
This implies one backward incompatible change for header-filtering. Our
ignore-header option used to filter against suffixes of absolute paths,
whereas now filter can receive working-directory relative paths in some
cases, possibly braking existing filters.
Chances of really braking users is pretty low:
- We'll still filter against absolute paths when header is outside the
working directory (e.g. /usr/bin/include/some/linux/header.h.)
- Most projects run builds in a working directory that's nested inside
the repository, hence relative paths still contain all the segments
relative to repository root and anything else is unlikely to be
meaningful. e.g. if a header is in
`$HOME/work/llvm-project/clang-tools-extra/header.h` with builds being
run in `$home/work/llvm-project/build`, we'll still filter against
`../clang-tools-extra/header.h` which has all the useful segments as a
suffix.
- This is also a change in how we handle symlinks, but this is aligned
with what we do in rest of our tools (clangd, tidy checks etc.). We
tend to not resolve any symlinks for the file.
I was wondering why my use of createClassType was generating structure
reccords, and it turns out the code is wrong (or for some reason i don't
understand the intended use of the API).
clang itself does not use that part of the API, so this flew under the
radar.
A dominance query of a block that is in a different function is
ill-defined, so assert that getNode() is only called for blocks that are
in the same function.
There are three cases, where this behavior did occur. LoopFuse didn't
explicitly do this, but didn't invalidate the SCEV block dispositions,
leaving dangling pointers to free'ed basic blocks behind, causing
use-after-free. We do, however, want to be able to dereference basic
blocks inside the dominator tree, so that we can refer to them by a
number stored inside the basic block.
Reverts #102780
Reland #101198Fixes#102784
Co-authored-by: Alexis Engelke <engelke@in.tum.de>
Currently we're merging the decls in ASTReaderDecl. But it is not so
convinient if we want to merge things in ASTReader.
This patch extract the funcitonality of merging decls from ASTReaderDecl
to a new class, ASTReaderMerger. Then it will be easier to merge decls
in ASTReader.
This may help the readability slightly too.
On 64bit targets we can promote i32 CTTZ nodes to i64 CTTZ_ZERO_UNDEF by setting the 32nd bit.
#57811 also queried about whether we should use BTS instead of MOVABS+OR to avoid a i64 immediate - I'm willing to tweak the DAGToDAG isel peephole for these cases if reviewers think it worthwhile. But most recent CPUs can actually handle MOVABS faster than BTS/C/R.......
Fixes#57811
This is a follow-up to #92289 that adds custom lowering of the new
`@llvm.experimental.vector.compress` intrinsic on AArch64 with SVE
instructions.
Some vectors have a `compact` instruction that they can be lowered to.
computeConstantDifference() can currently look through addrecs with
identical steps, and then through adds with identical operands (apart
from constants).
However, it fails to handle minor variations, such as two nested add
recs, or an outer add with an inner addrec (rather than the other way
around).
This patch supports these cases by adding a loop over the
simplifications, limited to a small number of iterations. The motivation
is the same as in #101339, to make
computeConstantDifference() powerful enough to replace existing uses of
`dyn_cast<SCEVConstant>(getMinusSCEV())` with it. Though as the IR test
diff shows, other callers may also benefit.
On Darwin we don't have any hardware that has SVE support, only SME.
Therefore we don't need to save VG for unwinders and can safely omit it.
This also fixes crashes introduced since this feature landed since Darwin's
compact unwind code can't handle the presence of VG anyway.
rdar://131072344
Check that the number of elements in the result type and the attribute
of an `llvm.mlir.constant` op matches. Also fix a broken test where that
was not the case.
Motivated by https://github.com/llvm/llvm-project/issues/101348
Although I don't want the tool's doc to explain the standard's wording,
the wording itself has some unspecified thing. So I feel it will be
helpful to make it clear. At least it may help us receive less invalid
issue reports.
Overview of changes:
- All memref input arguments are re-named to %mem.
- All vector input arguments are re-named to %vec.
- LIT variables are update to be consistent with input arguments.
- Renamed all output arguments as %res.
- Unified identation of `FileCheck` commands
- Separated tests (previously there was a big test containing a couple of tests)
- Replace hand-written parser/printer with auto-generated assembly
format.
- Remove implicit `gpu.module_end` terminator and use the `NoTerminator`
trait instead. (Same as `builtin.module`.)
- Turn the region into a graph region. (Same as `builtin.module`.)
An internal bug revealed that this form can be formed from existing
combines, and then fail to select. Use the same pattern as v2f64 ->
v4f64 (the instructions are moving bits around the actual type does not
matter here).
