This reverts commit 5125f476b2f90ccf157c78d73bc6fe14c4413a27.
This was reverted because it broke some debuginfod tests. Those have been fixed
now in #158141. Relanding now and hoping it sticks this time.
This patch updates the llvm-debuginfod tests to work with the lit
internal shell. One test was missing env before environment variables
and another was using a brace expansion.
The lldb-remote-linux-ubuntu bot (and only this bot) is still failing
for TestCortexMExceptionUnwind.py because the Target triple is
somehow inheriting a non-Darwin OS. I marked this API test
skipUnlessDarwin but this bot can be identified more specifically
by a skipIfRemote test. There's no benefit to running this test
remotely anyway; it doesn't execute any code.
Fixes#148052 .
When removing EH Pad blocks, the value defined by them becomes poison. These poison values are then used by `catchret` and `cleanupret`, which is invalid. This commit replaces those unreachable `catchret` and `cleanupret` instructions with `unreachable`.
In loop of `writeAndReadCoverageRegions`, `OutputFunctions[I].Filenames`
references to contents of `Filenames` after returning from
`readCoverageRegions` but `Filenames` will be cleared in next call of
`readCoverageRegions`, causes dangling reference.
The lifetime of the contents of `Filenames` must be equal or longer than
`OutputFunctions[I]`, thus it has been moved into `OutputFunctions[I]`
(typed `OutputFunctionCoverageData`).
Fix regression after 62f2641d603db9aef99dd5c434a1dfe7d3f56346. Previous
patch handled the register case, but the memory case snuck another use
of ptr_rc_tailcall hidden inside i64mem_TC
Restrict to VGPR only (VRegSrc_32) for mfma scale operands to workaround
a hardware design defect: For all Inline/SGPR constants, SP HW use bits
[30:23] as the scale.
TODO: We may still be able to allow Inline Constants/SGPR, with a proper
shift, to obtain a potentially better performance.
Fixes: SWDEV-548629
b50ad945dd4faa288 added umul_with_overflow simplifications to
InstSimplifyFolder (used by SCEVExpander) and 9b1b93766dfa34ee9 added
dead instruction cleanup to SCEVExpander.
Remove special handling of umul by 1, handled automatically due to the
changes above.
This patch fixes the problem, when after a `setVariable` request
pointers and references to the variable are not updated. VSCode doesn't
send a `variables` request after a `setVariable` request, so we should
trigger it explicitly via`invalidated` event .Also, updated
`writeMemory` request in similar way.
Clang and other frontends generally need the LLVM data layout string in
order to generate LLVM IR modules for LLVM. MLIR clients often need it
as well, since MLIR users often lower to LLVM IR.
Before this change, the LLVM datalayout string was computed in the
LLVM${TGT}CodeGen library in the relevant TargetMachine subclass.
However, none of the logic for computing the data layout string requires
any details of code generation. Clients who want to avoid duplicating
this information were forced to link in LLVMCodeGen and all registered
targets, leading to bloated binaries. This happened in PR #145899,
which measurably increased binary size for some of our users.
By moving this information to the TargetParser library, we
can delete the duplicate datalayout strings in Clang, and retain the
ability to generate IR for unregistered targets.
This is intended to be a very mechanical LLVM-only change, but there is
an immediately obvious follow-up to clang, which will be prepared
separately.
The vast majority of data layouts are computable with two inputs: the
triple and the "ABI name". There is only one exception, NVPTX, which has
a cl::opt to enable short device pointers. I invented a "shortptr" ABI
name to pass this option through the target independent interface.
Everything else fits. Mips is a bit awkward because it uses a special
MipsABIInfo abstraction, which includes members with codegen-like
concepts like ABI physical registers that can't live in TargetParser. I
think the string logic of looking for "n32" "n64" etc is reasonable to
duplicate. We have plenty of other minor duplication to preserve
layering.
---------
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
Co-authored-by: Sergei Barannikov <barannikov88@gmail.com>
Approximately handle avx512_{packssdw/packsswb/packusdw/packuswb} with
the existing handleVectorPackIntrinsic(), instead of relying on the
default (strict) handler.
This patch fixes a bug in BOLT's debug line emission where functions
that belong to multiple compilation units (such as inline functions in
header files) were not handled correctly. Previously, BOLT incorrectly
assumed that a binary function could belong to only one compilation
unit, leading to incomplete or incorrect debug line information.
### **Problem**
When a function appears in multiple compilation units (common scenarios
include):
* Template instantiated functions
* Inline functions defined in header files included by multiple source
files
BOLT would only emit debug line information for one compilation unit,
losing debug information for other CUs where the function was compiled.
This resulted in incomplete debugging information and could cause
debuggers to fail to set breakpoints or show incorrect source locations.
### **Root Cause**
The issue was in BOLT's assumption that each binary function maps to
exactly one compilation unit. However, when the same function (e.g., an
inline function from a header) is compiled into multiple object files,
it legitimately belongs to multiple CUs in the final binary.
Add a methodology to allow tracing. By default, this is disabled, but it
can be enabled for any OS that supports it.
Currently, only releaseToOSXXX functions have trace points added.
This is a second PR on this patch (first #155572), that fixes the
linking problem for `flang-aarch64-dylib` test.
The SupportLSP library was made a component library.
---
This PR moves the generic Language Server Protocol (LSP) server support
code that was copied from clangd into MLIR, into the LLVM tree so it can
be reused by multiple subprojects.
Centralizing the generic LSP support in LLVM lowers the barrier to
building new LSP servers across the LLVM ecosystem and avoids each
subproject maintaining its own copy.
The code originated in clangd and was copied into MLIR for its LSP
server. MLIR had this code seperate to be reused by all of their LSP
server. This PR relocates the MLIR copy into LLVM as a shared component
into LLVM/Support. If this is not a suitable place, please suggest a
better one.
A follow up to this move could be deduplication with the original clangd
implementation and converge on a single shared LSP support library used
by clangd, MLIR, and future servers.
What changes
mlir/include/mlir/Tools/lsp-server-support/{Logging, Protocol,
Transport}.h moved to llvm/include/llvm/Support/LSP
mlir/lib/Tools/lsp-server-support/{Logging, Protocol, Transport}.cpp
moved to llvm/lib/Support/LSP
and their namespace was changed from mlir to llvm
I ran clang-tidy --fix and clang-format on the whole moved files (last
two commits), as they are basically new files and should hold up to the
code style used by LLVM.
MLIR LSP servers where updated to include these files from their new
location and account for the namespace change.
This PR is made as part of the LLVM IR LSP project
([RFC](https://discourse.llvm.org/t/rfc-ir-visualization-with-vs-code-extension-using-an-lsp-server/87773))
This is useful to perform historical analyses, bisections or establish a
benchmarking baseline after making some changes on a branch. For
example, one can run benchmarks against `main` and easily compare them
to the results on the current feature branch with:
libcxx/utils/test-at-commit --commit $(git merge-base main HEAD) \
-B build/baseline -- <lit args>
libcxx/utils/libcxx-lit build/candidate <lit args>
libcxx/utils/compare-benchmarks \
<(libcxx/utils/consolidate-benchmarks build/baseline) \
<(libcxx/utils/consolidate-benchmarks build/candidate)
Doing this without these scripts would require checking out the desired
baseline, setting up the build directory and running the tests manually.
With these scripts, this can automatically be automated without dirtying
the current checkout.
Summary:
The vector target should be able to handle vector sizes that are
multiples of the native size, this is useful for implementing math
routines that want to temporarily use a high precision for example.
However, currently this will emit a warning on x86 if any function calls
are involved. https://godbolt.org/z/dK7hGndYh.
I believe that we should be able to relax the ABI restriction if the
functions are completely internal and there were no explicitly states
attributes to conflict. Because the ABI is not exported outside the TU
we should be safe to assume that it won't bite us. In the case that one
call has no features and other does, that will still cause an error. I
may be wrong on this assumption however.
Fixes: https://github.com/llvm/llvm-project/issues/128361
This reverts commit f869d7a1b100c9f9fc5bb06effcf4f73346c0919.
This broke some debuginfod tests that are not run by default in most CI
configurations. Reverting for now until I have time to update the tests
and figure out how to get them built locally.
Previously the checker `security.VAList` only tracked the set of the
inintialized `va_list` objects; this commit replaces this with a mapping
that can distinguish the "uninitialized" `va_list` objects from the
"already released" ones. Moreover, a new "unknown" state is introduced
to replace the slightly hacky solutions that checked the `Symbolic`
nature of the region.
In addition to sligthly improving the messages, this commit also
prepares the ground for a follow-up change that would introduce an
"indeterminate" state (which needs `va_end` but cannot be otherwise
used) to model the requirements of SEI CERT rule MSC39-C, which states:
> The va_list may be passed as an argument to another function, but
> calling va_arg() within that function causes the va_list to have an
> indeterminate value in the calling function. As a result, attempting
> to read variable arguments without reinitializing the va_list can have
> unexpected behavior.
This adds some basic verification for the new OPERAND_SHIFT_MSL and the
existing OPERAND_IMPLICIT_IMM_0 immediate operand types, that should be
264/272 or 0 respectively.
Both GPRPair and GPRPairNoX0 were using the same decoder before this
change, which meant that GPRPairNoX0 would disassemble zeroes to the
`X0_Pair`.
This ensures the NoX0 decoder correctly fails to decode zeroes.
