if x == 1,
x > 1 ? x : 1 return x, which is also 1.
x > 0 ? x : 1 return 1.
Reduce the number of load 1 instructions.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D132211
This allows `-DLLVM_ENABLE_RUNTIMES=libcxxabi` to work.
This functionality was removed in D125561 (among other such removals) as
dead code, because it was only available as part of the standalone build
before.
The functionality as added back as it was, except `target_include_directories` is used instead of the cruder `target_compile_options` (with an MSVC vs not MSVC conditional split). That is just wholly better.
Reviewed By: phosek, #libc_abi
Differential Revision: https://reviews.llvm.org/D132298
This has been officially deprecated since D112724, meaning the
deprecation warning is present in released 14 and 15.
This makes me think that now, shortly after the 15 release is branched,
is a good time to pull the trigger.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132324
When deinitializing, the allocation needs to be removed from the
allocation list of its associated reservation so that remaining
allocations can be deinitialized when releasing the reservation.
Differential Revision: https://reviews.llvm.org/D132313
When slab allocator is used, the MappingBase is not necessarily
the same as the original reservation base as the allocation could
be a part of the whole reservation.
In this case the original reservation address needs to be passed to
ExecutorSharedMemoryMapperService to associate the new allocation
with the original reservation.
Differential Revision: https://reviews.llvm.org/D132313
By the time SharedMemoryMapper destructor is called, the RPC
connection is no longer available causing the release() call to
always fail. Instead at this point only shared memory regions
can be unmapped safely.
Deinitializers are called and mapped memory is released at the
executor side by ExecutorSharedMemoryMapperService::shutdown()
instead. Memory can also be released earlier by calling release()
earlier before RPC connection is closed.
Differential Revision: https://reviews.llvm.org/D132313
The callback function was captured by reference but it lived on the
stack and was in danger of being overwritten and could cause a crash.
Differential Revision: https://reviews.llvm.org/D132313
Defaults to TCK_RecipThroughput - as most explicit calls were assuming TCK_RecipThroughput (vectorizers) or was just doing a before-vs-after comparison (vectorcombiner). Calls via getInstructionCost were just dropping the CostKind, so again there should be no change at this time (as getShuffleCost and its expansions don't use CostKind yet) - but it will make it easier for us to better account for size/latency shuffle costs in inline/unroll passes in the future.
Differential Revision: https://reviews.llvm.org/D132287
This adds a check for exported inline functions, that there is a definition in
the definition domain (which, in practice, can only be the module purview but
before any PMF starts) since the PMF definition domain cannot contain exports.
This is:
[dcl.inline]/7
If an inline function or variable that is attached to a named module is declared in
a definition domain, it shall be defined in that domain.
The patch also amends diagnostic output by excluding the PMF sub-module from the
set considered as sources of missing decls. There is no point in telling the user
that the import of a PMF object is missing - since such objects are never reachable
to an importer. We still show the definition (as unreachable), to help point out
this.
Differential Revision: https://reviews.llvm.org/D128328
I went over the output of the following mess of a command:
`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Reviewed By: #libunwind, MaskRay
Differential Revision: https://reviews.llvm.org/D130948
Now that MLIR is built with C++17, use the standard library equivalent of
`llvm::is_invocable`: `std::is_invocable`.
Differential Revision: https://reviews.llvm.org/D132318
This patch removes llvm::is_trivially_{copy/move}_constructible in
favor of std::is_trivially_{copy/move}_constructible.
The previous attempt to remove them in Dec 2020,
c8d406c93c, broke builds with "some
versions of GCC" according to
6cd9608fb3.
It's been 20 months since then, and the minimum requirement for GCC
has been updated to 7.1 from 5.1.
FWIW, I was able to build llvm with gcc 8.4.0.
Differential Revision: https://reviews.llvm.org/D132311
makeAbsolute was not updating the symbol address when applied to external
symbols.
This commit adds a unit test for makeAbsolute, and updates the makeExternal unit
test to check that makeExternal works correctly for absolute symbols.
Working back towards D130586.
Bolt didn't use `LLVM_LIBDIR_SUFFIX` before, and has no in-tree reverse
dependencies, it seems easier to add.
The change in LLVM itself is to prevent some unexpected `lib64` from
cropping up due to the `CMAKE_INSTALL_LIBDIR` defaulting logic.
Differential Revision: https://reviews.llvm.org/D132297
Use this instead of `*_LIBDIR_SUFFIX`, from which it is computed.
This gets us ready for D130586, in which `*_LIBDIR_SUFFIX` is
deprecated.
Differential Revision: https://reviews.llvm.org/D132300
This patch deprecates Any::hasValue as I've migrated all known uses of
it to Any::has_value. I'm planning to remove the deprecated method in
3 months or so.
Differential Revision: https://reviews.llvm.org/D132304
As Fortran 2018 C1806, each component of a derived type with the BIND
attribute shall be a nonpointer, nonallocatable data component with
interoperable type.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D131585
Remove barriers for firstprivate except if the variable is also
lastprivatized. Re-arrange code and put all last-privates inside a
single scf.if.
As OpenMP Spec 5.0, to avoid the data races, concurrent updates of the
original list item must be synchronized with the read of the original
list item that occurs as a result of the firstprivate clause. Adding
barrier(s) before and/or after the worksharing region would remove the
data races, and it is the application(user)'s job. However, when
one list item is in both firstprivate and lastprivate clauses, the
standard (https://www.openmp.org/spec-html/5.0/openmpsu105.html) states
the following:
```
If a list item appears in both firstprivate and lastprivate clauses, the
update required for the lastprivate clause occurs after all
initializations for the firstprivate clause.
```
So, the synchronization should be ensured by compiler such as emiting
one barrier since the lastprivate clause follows the reads of the
original list item performed for the initialization of each of the
firstprivate list item.
Add FIXME for two special cases, sections construct and linear clause.
The data race problem for single construct will be handled later.
This implementation is based on the discussion with OpenMP committee and
clang code (clang/lib/CodeGen/CGStmtOpenMP.cpp).
Reviewed By: kiranchandramohan, NimishMishra
Differential Revision: https://reviews.llvm.org/D131832
This patch implements Any::has_value for consistency with std::any in
C++17.
My plan is to deprecate Any::hasValue after migrating all of its uses
to Any::has_value. Since I am about to do so, this patch simply
replaces hasValue with has_value in the unit test instead of adding
tests for has_value.
Differential Revision: https://reviews.llvm.org/D132278
Follow-up to 7f1262a322. That patch avoided removing the
call, but it still allowed the constant-folded result. This
makes the behavior consistent with 1-arg libm folding: if the
call potentially raises an exception, then we just bail out.
It seems likely that there are other corner-cases like this,
but the tests are incomplete, so we have lived with these
discrepancies for a long time. This was untested before the
the constant folding was expanded in D127964.
For some reason cmake started selecting a 32-bit version of python on
Windows instead of the 64-bit version when building windows. Explicitly
setting the default python to 3.10 fixes this problem.
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D132280
Simon Pilgrim