Remove unused LO16 classes SReg_LO16_XM0_XEXEC, SReg_LO16_XEXEC_HI and
SReg_LO16_XM0.
Simplify the definition of SReg_32.
Add SReg_32_XEXEC and use it to improve SReg_1_XEXEC which previously
excluded M0 for no good reason.
Improve SReg_1 which previously excluded EXEC_HI for no good reason.
Differential Revision: https://reviews.llvm.org/D140012
Some of those .compile.fail.cpp tests had become incorrect and they
were not testing anything. In general, .compile.fail.cpp tests are
bad because they make it way too easy to write garbage tests. Indeed,
the test could fail to compile due to any reason whatsoever (even a
typo) and it would appear to work correctly.
Differential Revision: https://reviews.llvm.org/D138731
This patch implements P0960R3, which allows initialization of aggregates
via parentheses.
As an example:
```
struct S { int i, j; };
S s1(1, 1);
int arr1[2](1, 2);
```
This patch also implements P1975R0, which fixes the wording of P0960R3
for single-argument parenthesized lists so that statements like the
following are allowed:
```
S s2(1);
S s3 = static_cast<S>(1);
S s4 = (S)1;
int (&&arr2)[] = static_cast<int[]>(1);
int (&&arr3)[2] = static_cast<int[2]>(1);
```
This patch was originally authored by @0x59616e and completed by
@ayzhao.
Fixes#54040, Fixes#54041
Co-authored-by: Sheng <ox59616e@gmail.com>
Full write up : https://discourse.llvm.org/t/c-20-rfc-suggestion-desired-regarding-the-implementation-of-p0960r3/63744
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D129531
This allows DemandedBits to see the result of VSCALE will be at most
VScaleMax * some compile-time constant. This relies on the vscale_range()
attribute being present on the function, with a max set. (This is done by
default when clang is targeting AArch64+SVE).
Using this various redundant operations (zexts, sexts, ands, ors, etc)
can be eliminated.
Differential Revision: https://reviews.llvm.org/D138508
The `FunctionSpecialization` pass chooses specializations among the
opportunities presented by a single function and its calls,
progressively penalizing subsequent specialization attempts by
artificially increasing the cost of a specialization, depending on how
many specialization were applied before. Thus the chosen
specializations are sensitive to the order the functions appear in the
module and may be worse than others, had those others been considered
earlier.
This patch makes the `FunctionSpecialization` pass rank the
specializations globally, i.e. choose the "best" specializations
among the all possible specializations in the module, for all
functions.
Since this involved quite a bit of redesign of the pass data
structures, this patch also carries:
* removal of duplicate specializations
* optimization of call sites update, by collecting per
specialization the list of call sites that can be directly
rewritten, without prior expensive check if the call constants and
their positions match those of the specialized function.
A bit of a write-up up about the FuncSpec data structures and
operation:
Each potential function specialisation is kept in a single vector
(`AllSpecs` in `FunctionSpecializer::run`). This vector is populated
by `FunctionSpecializer::findSpecializations`.
The `findSpecializations` member function has a local `DenseMap` to
eliminate duplicates - with each call to the current function,
`findSpecializations` builds a specialisation signature (`SpecSig`)
and looks it in the duplicates map. If the signature is present, the
function records the call to rewrite into the existing specialisation
instance. If the signature is absent, it means we have a new
specialisation instance - the function calculates the gain and creates
a new entry in `AllSpecs`. Negative gain specialisation are ignored at
this point, unless forced.
The potential specialisations for a function form a contiguous range
in the `AllSpecs` [1]. This range is recorded in `SpecMap SM`, so we
can quickly find all specialisations for a function.
Once we have all the potential specialisations with their gains we
need to choose the best ones, which fit in the module specialisation
budget. This is done by using a max-heap (`std::make_heap`,
`std::push_heap`, etc) to find the best `NSpec` specialisations with a
single traversal of the `AllSpecs` vector. The heap itself is
contained with a small vector (`BestSpecs`) of indices into
`AllSpecs`, since elements of `AllSpecs` are a bit too heavy to
shuffle around.
Next the chosen specialisation are performed, that is, functions
cloned, `SCCPSolver` primed, and known call sites updated.
Then we run the `SCCPSolver` to propagate constants in the cloned
functions, after which we walk the calls of the original functions to
update them to call the specialised functions.
---
[1] This range may contain specialisation that were discarded and is
not ordered in any way. One alternative design is to keep a vector
indices of all specialisations for this function (which would
initially be, `i`, `i+1`, `i+2`, etc) and later sort them by gain,
pushing non-applied ones to the back. This has the potential to speed
`updateCallSites` up.
Reviewed By: ChuanqiXu, labrinea
Differential Revision: https://reviews.llvm.org/D139346
Change-Id: I708851eb38f07c42066637085b833ca91b195998
This allows to inline regions containing pure LLVM ops into their call
sites. (Note that this is not related to inlining of llvm.func but to
any the inlining of any Callable.) For now, we only allow the inlining
of Pure ops to be conservative but other ops may be considered inlinable
in the future.
Testing for purity of ops requires the C++ equivalent of the Pure trait
from SideEffectInterfaces.td, which this patch also provide. Its
implementation calls the C++ equivalents of the two traits that the Pure
trait is based on and, thus, has to be kept with the tablegen trait.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D139187
I found the interaction between SecondsToWait and
WaitUntilChildTerminates confusing. Rather than have a boolean to
ignore the value of SecondsToWait, combine these into one Optional
parameter.
This patch adds API support for the atk_pinned trait for omp_alloc.
It does not implement kmp_target_lock_mem and kmp_target_unlock_mem in libomptarget,
but prepares libomp for it. Patches to libomptarget to implement
lock/unlock coming after this one.
Reviewed by: jlpeyton, jdoerfert
Differential Revision: https://reviews.llvm.org/D138933
Reviewed by: vitalybuka, kito-cheng
These changes will allow to use HWASAN with RISCV64 architecture.
The majority of existing tests are passing with a few exceptions(see below).
The tests were running on QEMU, since currently there're no hardware with support
for J-extension.
For this feature to work the system must support PR_{SET,GET}_TAGGED_ADDR_CTRL
syscall. For now this is only available for a patched Linux kernel and QEMU with
enabled experimental J-extension.
Results of running HWASAN lit tests for RISC-V:
```
Unsupported : 6
Passed : 79
Expectedly Failed: 2
```
Tests are marked as expected to fail or unsupported either because of:
- android platform not being supported
- no support for legacy hwasan v1 mode
- test config explicitly uses aarch64 option
```
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/abort-message-android.cpp
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/cfi.cpp
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/lto.c
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/print-memory-usage-android.c
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/register-dump-read.c
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/try-catch.cpp
XFAIL: HWAddressSanitizer-riscv64 :: TestCases/stack-oob.c
XFAIL: HWAddressSanitizer-riscv64 :: TestCases/exported-tagged-global.c
```
Differential Revision: https://reviews.llvm.org/D131345
Once an LLVMContext has been told it needs to track pointer types, it can no
longer be used to parse opaque modules. However, we are likely (at least for a
while) to have old LTO .o files in the SDK that need to interoperate with
just-generated ones, so deciding opaqueness based on the first module read
causes linker failures.
This makes the llvm-c LTO interface parse any object it sees in opaque mode,
even if type data is present, which guarantees compatibility.
C++17 allows us to call constructors pair and tuple instead of helper
functions make_pair and make_tuple.
Differential Revision: https://reviews.llvm.org/D139828
This change extends the `ReplaceUnitExtents` pattern so that users can choose between of two strategies for generating rank reductions:
* CollapseShapeOp / ExpandShapeOp (was already implemented but code was cleaned up; default strategy)
* rank-reducing ExtractSliceOp / InsertSliceOp
Also add helper functions to the memref dialect that we already have on the tensor dialect: `getMixedSizes`, `createCanonicalRankReducingSubViewOp`, `rankReduceIfNeeded`.
We are using ReassociationIndices instead of ReassoicationExprs in many other places and this makes the code easier to read. Also adding a new test case (that also passed before).
Differential Revision: https://reviews.llvm.org/D139947
Always read bitcode according to the -opaque-pointers mode. Do not
perform auto-detection to implicitly switch to typed pointers.
This is a step towards removing typed pointer support, and also
eliminates the class of problems where linking may fail if a typed
pointer module is loaded before an opaque pointer module. (The
latest place where this was encountered is D139924, but this has
previously been fixed in other places doing bitcode linking as well.)
Differential Revision: https://reviews.llvm.org/D139940
This new function was added in b72f1ec9fbb14cd7d2f5112d2c52ef5cdd1aa94a,
but wasn't exported from the DLL on Windows.
This fixes the parallel/omp_parallel_if.c OpenMP testcase on
Windows.
If testing for a warning option like -Wno-<foo> with GCC, GCC won't
print any diagnostic at all, leading to the options being accepted
incorrectly. However later, if compiling a file that actually prints
another warning, GCC will also print warnings about these -Wno-<foo>
options being unrecognized.
This avoids warning spam like this, for every OpenMP source file that
produces build warnings with GCC:
cc1plus: warning: unrecognized command line option ‘-Wno-int-to-void-pointer-cast’
cc1plus: warning: unrecognized command line option ‘-Wno-return-type-c-linkage’
cc1plus: warning: unrecognized command line option ‘-Wno-covered-switch-default’
cc1plus: warning: unrecognized command line option ‘-Wno-enum-constexpr-conversion’
This matches how such warning options are detected and added in
llvm/cmake/modules/HandleLLVMOptions.cmake, e.g. like this:
check_cxx_compiler_flag("-Wclass-memaccess" CXX_SUPPORTS_CLASS_MEMACCESS_FLAG)
append_if(CXX_SUPPORTS_CLASS_MEMACCESS_FLAG "-Wno-class-memaccess" CMAKE_CXX_FLAGS)
This also matches how LLDB warning options were restructured for
GCC compatibility in e546bbfda0ab91cf78c096d8c035851cc7c3b9f3.
Differential Revision: https://reviews.llvm.org/D139922
This covers 128-bit loads, and atomicrmw operations without a single native
instruction. Using CAS saves has a better chance of succeeding with high
contention on some systems.
This refactors out the offset and address operand pattern matching into
a ComplexPattern, so that one pattern fragment can match the dynamic and
static (offset) addresses in all possible positions.
Split out from D139530, which also contained an improvement to global
address folding.
Differential Revision: https://reviews.llvm.org/D139631
Without this change this function could return nullptr if no further
transformation took place making InstCombine pass incorrectly report no
IR changes preventing analyses invalidation.
Differential Revision: https://reviews.llvm.org/D140004
Use FoldID to cache SignExtendExprs that get folded to a different
SCEV.
Depends on D137505.
Reviewed By: mkazantsev
Differential Revision: https://reviews.llvm.org/D137849
now with the fixed warning and updated lit tests
---
[RISC-V][HWASAN] Add support for HWASAN code instrumentation for RISC-V
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D131575
All the pointer-indirected cases are no longer relevant with
opaque pointers. To preserve at least some of the test intent,
switch to by value passing of the unnamed types. Otherwise we
wouldn't be testing anything at all.
On macOS, hardcoding the path of bash leads to a failure in executing
update_core_linalg_named_ops.sh, due to an old version of bash being
present in that location.
Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>
Differential Revision: https://reviews.llvm.org/D139942
This patch changes the `test-lower-to-llvm` pass into a named pipeline.
The functionality is unchanged but thanks to this change, we don't have
to pull the dependencies of all the passes that this pass calls.
In other words, `TestLowerToLLVMPass::getDependDialects` was supposed to
transitively declare all the dialects that were used in the union of all
the invoked passes.
NFC
Differential Revision: https://reviews.llvm.org/D139840
