We'd catch the tautological select pattern later anyways
due to constant folding, so that leaves PHI-like select,
but it does not appear to fire there.
Currently `createNodeForSelectOrPHI()` takes an Instruction,
and only works on the Cond that is an ICmpInst,
but that can be relaxed somewhat.
For now, simply rename the existing function,
and add a thin wrapper ontop that still does
the same thing as it used to.
https://alive2.llvm.org/ce/z/ULuZxB
We could transparently handle wider bitwidths,
by effectively casting iN to <N x i1> and performing the `add`
bit/element -wise, the expression will be rather large,
so let's not do that for now.
https://alive2.llvm.org/ce/z/aKAr94
We could transparently handle wider bitwidths,
by effectively casting iN to <N x i1> and performing the `umin`
bit/element -wise, the expression will be rather large,
so let's not do that for now.
https://alive2.llvm.org/ce/z/SMEaoc
We could transparently handle wider bitwidths,
by effectively casting iN to <N x i1> and performing the `umax`
bit/element -wise, the expression will be rather large,
so let's not do that for now.
The decision is perhaps arbitrary but I figure zeroing has no
dependency on the value being loaded.
Differential Revision: https://reviews.llvm.org/D119327
Previously the code in AArch64TargetLowering::ReconstructShuffle assumed
the input vectors were always fixed-width, however this is not always
the case since you can extract elements from scalable vectors and insert
into fixed-width ones. We were hitting crashes here for two different
cases:
1. When lowering a fixed-length vector extract from a scalable vector
with i1 element types. This happens due to the fact the i1 elements
get promoted to larger integer types for fixed-width vectors and leads
to sequences of INSERT_VECTOR_ELT and EXTRACT_VECTOR_ELT nodes. In this
case AArch64TargetLowering::ReconstructShuffle will still fail to make
a transformation, but at least it no longer crashes.
2. When lowering a sequence of extractelement/insertelement operations
on mixed fixed-width/scalable vectors.
For now, I've just changed AArch64TargetLowering::ReconstructShuffle to
bail out if it finds a scalable vector.
Tests for both instances described above have been added here:
(1) CodeGen/AArch64/sve-extract-fixed-vector.ll
(2) CodeGen/AArch64/sve-fixed-length-reshuffle.ll
Differential Revision: https://reviews.llvm.org/D116602
Some configurations of gdb pretty print std::deque and some don't. Make
this test run only on system-darwin (which uses lldb instead), otherwise
it will fail on some non-darwin machines and not others.
DR2390 clarifies that the argument to __has_cpp_attribute() needs to be
macro-expanded. Clang already supports this and tests it explicitly in
clang/test/Preprocessor/has_attribute.cpp.
Copy the test over to clang/test/CXX/drs/ so the make_cxx_drs script
picks it up.
Differential Revision: https://reviews.llvm.org/D119230
Clang already handles this fine, so add a test case to let the
make_cxx_dr_status script pick it up.
Differential Revision: https://reviews.llvm.org/D119224
This option allows callers to disable the warning from
https://clang.llvm.org/extra/clang-tidy/checks/performance-move-const-arg.html
that would warn on the following
```
void f(const string &s);
string s;
f(std::move(s)); // ALLOWED if performance-move-const-arg.CheckMoveToConstRef=false
```
The reason people might want to disable this check, is because it allows
callers to use `std::move()` or not based on local reasoning about the
argument, and without having to care about how the function `f` accepts
the argument. Indeed, `f` might accept the argument by const-ref today,
but change to by-value tomorrow, and if the caller had moved the
argument that they were finished with, the code would work as
efficiently as possible regardless of how `f` accepted the parameter.
Reviewed By: ymandel
Differential Revision: https://reviews.llvm.org/D119370
Replace matchSelectPattern pattern match with the more general m_SMin so that it can handle smin intrinsics as well as the icmp+select pattern
Noticed while reviewing regressions from D98152
This patch factors out space information from IntegerPolyhedron, PresburgerSet
and PWMAFunction to PresburgerSpace and its extension with local variables,
PresburgerLocalSpace.
Generally any new data structure additions in Presburger library will require
space information. This patch removes the need to duplicate the space
information.
Reviewed By: arjunp
Differential Revision: https://reviews.llvm.org/D119280
In preparing for module mangling changes I noticed some issues with
the way we check for std::basic_string instantiations and friends.
*) there's a single routine for std::basic_{i,o,io}stream but it is
templatized on the length of the name. Really? just use a
StringRef, rather than clone the entire routine just for
'basic_iostream'.
*) We have a helper routine to check for char type, and call it from
several places. But given all the instantiations are of the form
TPL<char, Other<char> ...> we could just check the first arg is char
and the later templated args are instantiating that same type. A
simpler type comparison.
*) Because basic_string has a third allocator parameter, it is open
coded, which I found a little confusing. But otherwise it's exactly
the same pattern as the iostream ones. Just tell that checker about
whether there's an expected allocator argument.[*]
*) We may as well return in each block of mangleStandardSubstitution
once we determine it is not one of the entities of interest -- it
certainly cannot be one of the other kinds of entities.
FWIW this shaves about 500 bytes off the executable.
[*] I suppose we could also have this routine a tri-value, with one to
indicat 'it is this name, but it's not the one you're looking for', to
avoid later calls trying different names?
Reviewd By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119333
I discovered some demangler problems:
a) parsing of new expressions was broken, ignoring any 'gs' prefix
b) (when #a is fixed) badly formatted global new expressions
c) formatting of new and delete failed to correctly add whitespace
(a) happens as parseExpr swallows the 'gs' prefix but doesn't pass it
to 'parseNewExpr'. It seems simpler to me to just code the new
expression parsing directly in parseExpr, as is done for delete
expressions.
(b) global new should be rendered something like '::new T' not
'::operator new T'
(c) is resolved by being a bit more careful with whitespace.
Best shown with some examples (don't worry that these symbols are for
impossible instantiations, that's not the point):
Old behaviour:
build/bin/llvm-cxxfilt _ZN2FnIXgsnw_iEEXna_ipiLi4EEEEEvv _ZN2FnIXnwLj4E_iEEXgsnaLj4E_ipiLi4EEEEEvv _ZN2FnIXgsdlLi4EEXdaLi4EEEEvv _ZN2FnIXdlLj4EEXgsdaLj4EEEEvv
void Fn<new int, new[] int(4)>() // No ::new
void Fn<new (4u)int, new[] (4u)int(4)>() // No ::new, poor whitespace
void Fn<::delete4, delete[] 4>() // missing necessary space
void Fn<delete4u, ::delete[] 4u>() // missing necessary space
New behaviour:
build/bin/llvm-cxxfilt _ZN2FnIXgsnw_iEEXna_ipiLi4EEEEEvv _ZN2FnIXnwLj4E_iEEXgsnaLj4E_ipiLi4EEEEEvv _ZN2FnIXgsdlLi4EEXdaLi4EEEEvv _ZN2FnIXdlLj4EEXgsdaLj4EEEEvv
void Fn<::new int, new[] int(4)>()
void Fn<new(4u) int, ::new[](4u) int(4)>()
void Fn<::delete 4, delete[] 4>()
void Fn<delete 4u, ::delete[] 4u>()
Binutils' behaviour:
c++filt _ZN2FnIXgsnw_iEEXna_ipiLi4EEEEEvv _ZN2FnIXnwLj4E_iEEXgsnaLj4E_ipiLi4EEEEEvv _ZN2FnIXgsdlLi4EEXdaLi4EEEEvv _ZN2FnIXdlLj4EEXgsdaLj4EEEEvv
void Fn<::new int, new int(4)>()
void Fn<new (4u) int, ::new (4u) int(4)>()
void Fn<::delete (4), delete[] (4)>()
void Fn<delete (4u), ::delete[] (4u)>()
The new and binutils demanglings are the same modulo some whitespace and optional parens.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118476
The lowering code for shuffle_vector has a code path that looks through
extract_subvector, this code path did not properly account for the
potential presense of larger than Neon vector types and could produce
unselectable DAG nodes.
Differential Revision: https://reviews.llvm.org/D119252
Even after D86621 <https://reviews.llvm.org/D86621>, `clang -m32` on
Solaris/sparcv9 doesn't inline atomics with 8-byte operands, unlike `gcc`.
This leads to many link failures in the testsuite (undefined references to
`__atomic_load_8` and `__sync_val_compare_and_swap_8`. Until a proper
codegen fix can be implemented, this patch works around the first of those
by linking with `-latomic`.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D118021
It's inevitable that optimisation passes will fail to update debug-info:
when that happens, it's best if the compiler doesn't crash as a result.
Therefore, downgrade a few assertions / failure modes that would crash
when illegal debug-info was seen, to instead drop variable locations. In
practice this means that an instruction reference to a nonexistant or
illegal operand should be tolerated.
Differential Revision: https://reviews.llvm.org/D118998
Instead of determining the alignment based on the pointer element
type (which is incompatible with opaque pointers), make use of
alignment annotations added by the frontend.
In particular, clang will add alignment attributes to OpenCL kernels
since D118894. Other frontends might need to be adjusted to add
the attribute as well.
Differential Revision: https://reviews.llvm.org/D119247
And XFAIL debuginfo-tests/llgdb-tests/asan-deque.cpp on !system-darwin.
On non-darwin systems these tests use gdb and this one fails because gdb
doesn't pretty-print std::deque (the elements of the deque are not printed so
the CHECK lines fail).
Differential Revision: https://reviews.llvm.org/D118760
This reverts commit 0df522969a.
Additional checks are added to fix the detection of the last memory region
in GetMemoryRegions or repeating the "memory region" command when the
target has non-address bits.
Normally you keep reading from address 0, looking up each region's end
address until you get LLDB_INVALID_ADDR as the region end address.
(0xffffffffffffffff)
This is what the remote will return once you go beyond the last mapped region:
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0001000000000000-0xffffffffffffffff) ---
Problem is that when we "fix" the lookup address, we remove some bits
from it. On an AArch64 system we have 48 bit virtual addresses, so when
we fix the end address of the [stack] region the result is 0.
So we loop back to the start.
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0000000000000000-0x0000000000400000) ---
To fix this I added an additional check for the last range.
If the end address of the region is different once you apply
FixDataAddress, we are at the last region.
Since the end of the last region will be the last valid mappable
address, plus 1. That 1 will be removed by the ABI plugin.
The only side effect is that on systems with non-address bits, you
won't get that last catch all unmapped region from the max virtual
address up to 0xf...f.
[0x0000fffff8000000-0x0000fffffffdf000) ---
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
<ends here>
Though in some way this is more correct because that region is not
just unmapped, it's not mappable at all.
No extra testing is needed because this is already covered by
TestMemoryRegion.py, I simply forgot to run it on system that had
both top byte ignore and pointer authentication.
This change has been tested on a qemu VM with top byte ignore,
memory tagging and pointer authentication enabled.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D115508
This patch introduces the FIRInlinerInterface.
This class defines the interface for handling inlining of FIR calls.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D119340
Co-authored-by: Jean Perier <jperier@nvidia.com>
With the benefit of D88392, instruction encoding and mnemonic testing can be
achieved within MIR files before AsmParser is ready. This patch adds such
tests which cover all basic integer instructions we defined in previous patch.
Similarly those tests will be rewrote by .s and moved to test/MC/LoongArch.
Differential revision: https://reviews.llvm.org/D115862
This is a split patch of D115862 which adds a --bits-endian option to
extract-section to make it possible to print bits in specified endianness.
It means that we can print instruction encoding of some targets like LoongArch
as bits[0] to bits[31] from right to left by specifing --bits-endian little.
Differential revision: https://reviews.llvm.org/D116100
This patch introduces basic tablegen infra such as
LoongArch{InstrFormats,InstrInfo,RegisterInfo,CallingConv,}.td.
For now, only add instruction definitions for LoongArch basic integer
operations.
Our initial target is a working MC layer rather than codegen,
so appropriate SelectionDAG patterns will come later.
Differential revision: https://reviews.llvm.org/D115861
This patch registers the 'loongarch32' and 'loongarch64' targets. Also adds a
simple testcase to check the output of llc --vesion containing the targets.
Differential revision: https://reviews.llvm.org/D115860
This patch adds necessary definitions for LoongArch ELF files, including
relocation types. Also adds initial support to ELFYaml, llvm-objdump,
and llvm-readobj in order to work with LoongArch ELFs.
Differential revision: https://reviews.llvm.org/D115859
This patch builds on top of D119197 to canonicalize floating-point
SPLAT_VECTOR as RISCVISD::VFMV_V_F_VL as a pre-process ISel step.
This primarily benefits scalable-vector VP code, where our VP patterns
only match VFMV_V_F_VL to reduce the burden on our ISel patterns, but
where at the same time, scalable-vector code doesn't custom-legalize
SPLAT_VECTOR.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D117670
These patterns were omitted because clang only allows converting between
these types using intrinsics, but other front-ends or optimisation
passes may want to use them.
Differential revision: https://reviews.llvm.org/D119354
Roman Lebedev