For the NVVM Dialect tests under Target/LLVMIR/nvvm/ dir,
we verify the lowering to the intrinsics using mlir-translate.
Remove the -verify-diagnostics option from the cmd-line
for these tests since all the verifier checks are tested through
the nvvmir-invalid.mlir file. Similarly, remove the split-input-file
option which is not relevant here.
Update a few remaining links in the NVVMOps.td file.
All the reference links follow the same style now.
Rename the tcgen05-barriers.mlir file to tcgen05-commit.mlir
and move the wait/fence tests to a separate file.
Signed-off-by: Durgadoss R <durgadossr@nvidia.com>
These concepts don't exist for MCRegister.
I think there is a need for virtual registers in MCRegister for NVPTX,
SPIR-V and WebAssembly, but those should not be confused with Register's
virtual register. I will try to make a separate proposal for that with a
real interface.
Currently, all request handlers are implemented as free functions in
lldb-dap.cpp. That file has grown to over 5000 lines and is starting to
become hard to maintain. This PR moves the request handlers into their
own class (and file), together with their documentation.
This PR migrates about a third of the request handlers and the rest will
be migrated in subsequent commits. I'm merging this in an incomplete
state because almost any lldb-dap change is going to result in merge
conflicts and migrating request handlers one by one is easier to review.
It's possible to have an `ld-path` point to a linker that doesn't have
the `ld.lld` filename (e.g. linker wrapper that may emit telemetry
before invoking the linker). This was causing mis-compilations with
fatLTO since the check couldn't reliably detect that it was using lld.
Instead, rely on the value from `-fuse-ld` to determine whether lld is
enabled.
The latter is simpler and generalizes the OpenEmbedded special case
introduced in https://reviews.llvm.org/D48862
(they have /usr/lib64 but not /usr/lib)
Full build precommit bots were failing due to mis-alignment of atomics
in hermetic tests. This PR enforces the alignment for the bump allocator
of hermetic test framework.
Fixes https://github.com/llvm/llvm-project/issues/128185.
setType is unneeded (and AsmPrinter tries not to modify symbols).
AsmPrinter. MCSA_ELF_TypeFunction is available on all
targets using getSymbolPreferLocal.
Pull Request: https://github.com/llvm/llvm-project/pull/128138
Without this patch `basic_string` cannot be properly resized to be
`max_size()` elements in size, even if an allocation is successful.
`__grow_by` allocates one less element than required, resulting in an
out-of-bounds access. At the same time, `max_size()` has an off-by-one
error, since there has to be space to store the null terminator, which
is currently ignored.
Check that the input register is an inreg argument to the parent
function. (See the comment in `IntrinsicsAMDGPU.td`.)
This LLVM defect was identified via the AMD Fuzzing project.
---------
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
They were instantiated with only a single type and union-members
themselves. By putting the types directly into a union, they are still
left uninitialized by default.
Current state in scripted process expects [all the
modules](912b154f3a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp (L498))
passed into "get_loaded_images" to load successfully else none of them
load. Even if a module loads fine, [but has already been
appended](912b154f3a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp (L495))
it still fails. This is restrictive and does not help our usecase.
**Usecase**: We have a parent scripted process using coredump +
tombstone.
1) Scripted process uses child elf-core process to read memory dump
2) Uses tombstones to pass thread names and modules.
We do not know whether the modules will be successfully downloaded
before creating the scripted process. We use [python module
callbacks](a57e58dbfa/lldb/source/Target/Platform.cpp (L1593))
to download a module from symbol server at LLDB load time when the
scripted process is being created. The issue is that if one of the
symbol is not found from the list specified in tombstone, none of the
modules load in scripted process. Even if we ensure symbols are present
in symbol server before creating the scripted process, if the load
address is wrong or if the module is already appended, all module loads
are skipped.
**Solution**: Pass in a custom boolean option arg for every module from
python scripted process plugin which will indicate whether to ignore the
module load error. This will provide the flexibility to user for loading
the successfully fetched modules into target while ignoring the failed
ones
---------
Co-authored-by: rchamala <rachamal@fb.com>
While processing library link options that check search paths (-lx, -hidden-lx,
etc.) we shouldn't generate candidate paths with extensions that are invalid
for the option being visited (e.g. -hidden-lx only applies to archives, so we
shouldn't generate candidates with `.so` extensions).
Note: Candidate extensions should probably be further filtered based on the OS
of the executing process. This patch is a step in the right direction though.
