This restores D132311, which was reverted in
29c841ce93e087fa4e0c5f3abae94edd460bc24a (Sep 2022) due to certain files
not buildable with GCC 7.3.0. The previous attempt was reverted by
6cd9608fb37ca2418fb44b57ec955bb5efe10689 (Dec 2020).
This time, GCC 7.3.0 has existing build errors for a long time due to
structured bindings for many files, e.g.
```
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:9098:13: error: cannot decompose class type ‘std::pair<llvm::Value*, const llvm::SCEV*>’: both it and it
s base class ‘std::pair<llvm::Value*, const llvm::SCEV*>’ have non-static data members
for (auto [_, Stride] : Legal->getLAI()->getSymbolicStrides()) {
^~~~~~~~~~~
```
... and also some `error: duplicate initialization of` instances due to llvm/Transforms/IPO/Attributor.h.
---
GCC 7.5.0 has a bug that, without this change, certain `SmallVector` with a `std::pair` element type like `SmallVector<std::pair<Instruction * const, Info>, 0> X;` lead to spurious
```
/tmp/opt/gcc-7.5.0/include/c++/7.5.0/type_traits:878:48: error: constructor required before non-static data member for ‘...’ has been parsed
```
Switching to std::is_trivially_{copy/move}_constructible fixes the error.
Switch the parse of command line options from llvm::cl to OptTable.
The motivation for this change is to continue adding llvm based tools
to the llvm driver multicall. For more information about the proposal
and motivation, please see https://discourse.llvm.org/t/rfc-llvm-busybox-proposal/58494
Reviewed By: leonardchan
Differential Revision: https://reviews.llvm.org/D155119
`FixableGadget`s are not always associated with variables that are unsafe
(warned). For example, they could be associated with variables whose
unsafe operations are suppressed or that are not used in any unsafe
operation. Such `FixableGadget`s will not be fixed. Removing these
`FixableGadget` as early as possible helps improve the performance
and stability of the analysis.
Reviewed by: NoQ (Artem Dergachev), t-rasmud (Rashmi Mudduluru)
Differential revision: https://reviews.llvm.org/D155524
It's necessary for the assert_fail function, so it needs to stay in for
the moment.
Reviewed By: alfredfo
Differential Revision: https://reviews.llvm.org/D156275
instead of DW_ELE_start_length in debug_rnglists section
This patch tries to reduce the size of the debug_rnglist section by
replacing the DW_RLE_start_length opcodes currently emitted by dsymutil
in favor of using DW_RLE_base_addressx + DW_RLE_offset_pair instead.
The DW_RLE_start_length is one AddressSize followed by a ULEB per entry,
whereas, the DW_RLE_base_addressx + DW_RLE_offset_pair will use one ULEB
for the base address, and then the DW_RLE_offset_pair is a pair of
ULEBs. This will be more efficient.
Differential Revision: https://reviews.llvm.org/D156166
When inline assembly code requests more registers than available, the
MachineInstr::emitError function in the RegAllocFast pass emits an error
but doesn't stop the pass, and then the compiler crashes later with an
assertion failure. This commit, mimicking the RegAllocGreedy pass, assigns
a random physical register, and therefore avoids the crash after producing
the diagnostic. This problem has been observed for both rustc and clang,
while it doesn't occur in gcc.
Zero region operations return true for both isBeforeAllRegions and
isAfterAllRegions when using WalkStage. The bytecode walk only
expects region holding operations in the after regions path, so
guard against that.
Many sources show that xxh3 is much better than xxh64. This particular
instance may or may not have noticeable difference, but this change
moves us toward removing xxHash64.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D155992
member.
Previously, we wouldn't do this if the first member loaded is within a
definition that's added to a class via an update record, which happens
when template instantiation adds a class definition to a declaration
that was imported from an AST file.
This would lead to classes having member functions whose getParent
returned a class declaration that wasn't the primary definition, which
in turn caused the vtable builder to build broken vtables.
I don't yet have a reduced testcase for the wrong-code bug here, because
the setup required to get us into the broken state is very subtle, but
have confirmed that this fixes it.
We currently only support lazy loading for regions that
statically implement the IsolatedFromAbove trait, but that
limits the amount of operations that can be lazily loaded. This review
lifts that restriction by computing which operations have isolated
regions when numbering, allowing any operation to be lazily loaded
as long as it doesn't use values defined above.
Differential Revision: https://reviews.llvm.org/D156199
We currently encode each region as a separate section, but
the reader expects all of the regions to be in the same section.
This updates the writer to match the behavior that the reader
expects.
Differential Revision: https://reviews.llvm.org/D156198
As of 0beffb854209a41f31beb18f9631258349a99299 there is a CMake
function to actually calculate the relative path to the clang resource
directory. Currently we have some bespoke logic that looks in a few
places, but with this new function we should be able to eliminate some
complexity here.
Also, I moved the functionality from LLDBConfig to LLDBStandalone since
it is only used in standalone builds.
Differential Revision: https://reviews.llvm.org/D156270
Consider the following statement:
const char* foo = "foo";
For the sub-AST:
`-ImplicitCastExpr <col:19> 'const char *' <NoOp>
`-ImplicitCastExpr <col:19> 'char *' <ArrayToPointerDecay>
`-StringLiteral <col:19> 'char[4]' lvalue "foo"
The address of the StringLiteral can be emitted as the Constant.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D156185
This revision significantly simplifies the specification and implementation of mapping loops to GPU ids.
Each type of mapping (block, warpgroup, warp, thread) now comes with 2 mapping modes:
1. a 3-D "grid-like" mode, subject to alignment considerations on threadIdx.x, on which predication
may occur on a per-dimension 3-D sub-rectangle basis.
2. a n-D linearized mode, on which predication may only occur on a linear basis.
In the process, better size and alignment requirement inference are introduced along with improved runtime verification messages.
The `warp_dims` attribute was deemed confusing and is removed from the transform in favor of better size inference.
Differential Revision: https://reviews.llvm.org/D155941
Resolve https://github.com/llvm/llvm-project/issues/61932. We should add the validation.
LLVM can't handle IR where subprogram definitions are nested within DICompositeType when doing LTO builds, because there's no good way to cross the CU boundary to insert a nested DISubprogram definition in one CU into a type defined in another CU.
The test cases `cross-cu-inlining-2.ll` and `cross-cu-inlining-ranges.ll` can be deleted. In the `cross-cu-inlining-2.ll`, the low pc and high pc of the CU are also incorrect.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D152095
The attribute on operations in ops.mlir were not DeclareAttr but
DataClauseAttr with the acc.declare attribute name. Update the test
and the verifier to work correctly with the expected DeclareAttr.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156262
This removes the need of ScopedUnlock and make the future use of
condition variable easier to wake up waiting threads.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D156147
This is a complete fix for CompleteLoadGroups introduced in
D154309. We need to check for dependency between A and every member of
the load Group of B.
This patch also fixes another miscompile seen when we incorrectly sink stores
below a depending load (see testcase in
interleaved-accesses-sink-store-across-load.ll). This is fixed by
releasing store groups correctly.
Differential Revision: https://reviews.llvm.org/D155520
It looks like the definition was removed in cd21d541397e but the
declaration was not. Surprisingly (to me), that doesn't seem to produce
any kind of diagnostic.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D156182
Improves the ability of ConstExprEmitter to evaluate constants.
Found by adding asserts to ConstantEmitter::tryEmitPrivate to find cases
where ConstExprEmitter::Visit() fails to resolve (obvious) constants.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D156154
Similar to D156016 for MapVector.
This brings back commit fae7b98c221b5b28797f7b56b656b6b819d99f27 with a
fix to llvm/unittests/Support/ThreadPool.cpp's `_WIN32` code path.
made checking for invalid cache entries and setting invalid cache
entries more implicit and clear.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D155983
Split cache::retrieve() into separate functions. One that retrieves
the cached block and another that sets the header and MTE environment.
These were split so that the retrieve function could be more easily
changed in the future and so that the retrieve function had the sole
purpose of retrieving a CachedBlock.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D155660
In code object 5 (https://llvm.org/docs/AMDGPUUsage.html#code-object-v5-metadata) the AMDGPU backend added the .uses_dynamic_stack bit to the kernel meta data to identity kernels which have compile time indeterminable stack usage (indirect function calls and recursion mainly). This patch adds this information to the output of the kernel-resource-usage remarks.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D156040
Author: Corbin Robeck <corbin.robeck@amd.com>
When the process is contiuned using an lldb command expression the thread state in VS Code is never informed and will be out of sync with the current state of the process. The new event will fire whenever the process is continued and keeps the debugger in sync with the dap client.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D154989
Previously displaying a failed assert would involve a runtime integer to
string conversion. This patch changes that to be a compile time string
conversion.
This was inspired by a comment by JonChesterfield on https://reviews.llvm.org/D155899
Reviewed By: lntue, sivachandra, JonChesterfield
Differential Revision: https://reviews.llvm.org/D156168
Fixes uglification in mdspan deduction guides, which CI
did not test for until recently. The CI modification
and mdspan testing overlapped, so mdspan landed with green
CI, and the CI modification landed too.
Make most assertions in mdspan and its helper classes
trigger during a hardened build in order to catch
out of bounds access errors.
Also moves all mdspan assertions tests from libcxx/test/std
to libcxx/test/libcxx.
Differential Revision: https://reviews.llvm.org/156181
These may serve as example and showcase of the MLIR binary footprint.
Right now a release build of these tools on a linux machine shows:
- mlir-cat: 2MB
This includes the Core IR, the textual parser/printer, the support for
bytecode.
- mlir-minimal-opt: 3MB
This adds all the tooling for an mlir-opt tool: the pass infrastructure
and all the instrumentation associated with it.
- mlir-miminal-opt-canonicalize: 4.8MB
This add the canonicalizer pass, which pulls in all the pattern/rewrite
machinery, including the PDL compiler and intepreter.
Differential Revision: https://reviews.llvm.org/D156218
Change default behavior in Clang-tidy and skip by default
module headers parsing. That functionality is buggy and
slow in C++20, and provide tiny benefit.
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D156161
This is an enhancement for the locate module callback.
https://discourse.llvm.org/t/rfc-python-callback-for-target-get-module/71580/6
On Android remote platform, module UUID is resolved by
Platform::GetRemoteSharedModule. Which means the current
Target::CallLocateModuleCallbackIfSet() call undesirably is not able to pass the
module UUID to the locate module callback.
This diff moves the CallLocateModuleCallbackIfSet() implementation from Target
to Platform to allows both Target and Platform can call it. One is from the
current Target call site, and second is from Platform after resolving the module
UUID.
As the result of this change, the locate module callback may be called twice
for a same module on remote platforms. And it should be ok.
- First, without UUID.
- The locate module callback is allowed to return an error
if the callback requires UUID.
- Second, with UUID, if the first callback call did not return a module.
Differential Revision: https://reviews.llvm.org/D156066
