This is a work in progress refactor to add explicit types instead of
generic 'llvm::json::Value' types to the DAP protocol.
This updates RequestHandler to have take the type of the arguments and
response body for serialization for requests.
The 'source' and 'disconnect' request is updated to show how the new
flow
works and includes serialization handling for optional arguments and
'void'
responses.
This is built on top of #130026
---------
Co-authored-by: Adrian Vogelsgesang <adrian.vogelsgesang@tum.de>
This is split off from #131300.
A VPReductionRecipe will never have a AnyOf or FindLastIV recurrence, so
when it calls createReduction it always calls createSimpleReduction.
If we replace the call then it leaves createReduction with one user in
VPInstruction::ComputeReductionResult, which we can inline and then
remove.
When negating an FMA opcode, a new node created for a negated FMA
operand may be deleted while recursively negating another FMA operand.
This causes the following assertion to fail:
```
llc: /root/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:7686: llvm::SDValue llvm::SelectionDAG::getNode(unsigned int, const llvm::SDLoc&, llvm::EVT, llvm::SDValue, llvm::SDValue, llvm::SDValue, llvm::SDNodeFlags): Assertion `N1.getOpcode() != ISD::DELETED_NODE && N2.getOpcode() != ISD::DELETED_NODE && N3.getOpcode() != ISD::DELETED_NODE && "Operand is DELETED_NODE!"' failed.
```
This patch adds a temporary handle on the new negated nodes to prevent
them from being deleted.
For eg. see https://godbolt.org/z/Tq4PvnKM4 .
Co-authored-by: Vineet Kumar <vineetk@hpe.com>
Until recently checkFeature was quite slow. #130936
I was curious where we use checkFeature and noticed these. I thought we
could use hasFeature instead of going through strings.
Fixes#131359
After #129645, a first-order recurrence will no longer have it's splice
costed if the VPInstruction::FirstOrderRecurrenceSplice has no users and
is dead.
The legacy cost model didn't account for this, so this accounts for it
in planContainsAdditionalSimplifications to avoid the "VPlan cost model
and legacy cost model disagreed" assertion.
More people have been interested in exegesis recently, so having a point
of contact would probably be good. Exegesis also never had proper code
owners in the previous system, so adding them now is a decent step
forward.
I'm nominating myself as I'm interested in pushing the project further,
and have a decent amount of experience with the code base. Two of the
original authors, Clement and Guillaume, now have different priorities
at work and are thus not as invested into maintaining exegesis anymore.
This commit adds support for the following ldmatrix extensions
introduced in PTX 8.6
- Support for m16n16 with b8 type with mandatory transpose
- Support for m16n16 with m8n16 with source and desitination formats
The above extensions are only supported on sm_100a, sm_101a, sm_120a
Please refer the PTX ISA for more information:
https://docs.nvidia.com/cuda/parallel-thread-execution/#warp-level-matrix-instructions-ldmatrix
This reverts commit
87b7f63a11,
reapplying
7e66cf74fb
with a small (and probably temporary)
change to generate more debug info to help with diagnosing buildbot
issues.
Create the Function* handles for all functions we see, but delay the
actual compilation until we really call the function. This speeds up
compile times with the new interpreter a bit.
Implement new pseudos with the suffix _t16 which have VGPR_16 as the
store src or load dst. This affects LDS 8 and 16-bit loads and stores.
Lower the pseudos to the existing real Hi/Lo instructions in MC inst
layer with VGPR_32 src or dst
---------
Co-authored-by: Abhinav <abhinav.garg@amd.com>
There's never any point to adding a `virtual` specifier to methods in a
`final` class, since the class can't be subclassed. This adds a warning
when we notice this happening, as suggested in #131108.
We don't currently implement the second part of the suggestion, to warn
on `virtual` methods which are never overridden anywhere. Although it's
feasible to do this for things with internal linkage (so we can check at
the end of the TU), it's more complicated to implement and it's not
clear it's worth the effort.
I tested the warning by compiling chromium and clang itself. Chromium
resulted in [277 warnings across 109
files](https://github.com/user-attachments/files/19234889/warnings-chromium.txt),
while clang had [38 warnings across 29
files](https://github.com/user-attachments/files/19234888/warnings-clang.txt).
I inspected a subset of the warning sites manually, and they all seemed
legitimate.
This warning is very easy to fix (just remove the `virtual` specifier)
and I haven't seen any false positives, so it's suitable for
on-by-default. However, I've currently made it off-by-default because it
fires at several places in the repo. I plan to submit a followup PR
fixing those places and enabling the warning by default.
In corner situations, the vectorization pass may face to lower a conv2d
op and assert in a completely irrelevant location in
vectorizeConvolution() subroutine.
~~This PR rejects the conv2d op early and make the asserted routine to
return failure as a defensive workaround.~~
In addressing this, the PR moved all condition check away from the
`Conv1dGenerator` into the `convOpPreconditionCheck()` function. This
makes the unsupported ops such as conv2d to be rejected early and leave
a cleaner `Conv1dGenerator` constructor.
Move `FindLibcCommonUtils` from LLVM's CMake module directory to the
shared top-level CMake directory, as the module is intended to be used
from within the source tree rather than the installed LLVM version. This
fixes standalone offload builds after #131205.
This patch attempts to provide a fix for an issue that appears when the
`__kmp_dist_for_static_init` function is called from a serialized team.
This is triggered by code generated by flang for `distribute parallel
do` constructs whenever an `if` clause for the `parallel` leaf construct
is present. This results in the introduction of a call to
`__kmpc_fork_call_if` in place of `__kmpc_fork_call`. When it evaluates
to `false`, it defers execution to `__kmp_serialized_parallel`, which
creates a new serial team that is picked up by
`__kmp_dist_for_static_init`, resulting in an incorrect `team` pointer
that causes the `nteams == (kmp_uint32)team->t.t_parent->t.t_nproc`
assertion to fail.
The sequence of calls replicating this issue can be summarized as:
- `__kmpc_fork_teams`
- `__kmpc_fork_call_if`
- `__kmpc_dist_for_static_init_*`
Since I am not familiar with the implementation of the OpenMP runtime,
it is possible that the above sequence of calls is incorrect, or that
the bug can be better fixed in another way, so I am open to discussing
this.
The following Fortran program can be compiled with flang to show the
issue:
```f90
! Compile and run: flang -fopenmp test.f90 -o test && ./test
! Check LLVM IR: flang -fc1 -emit-llvm -fopenmp test.f90 -o -
program main
implicit none
integer, parameter :: n = 10
integer :: i, idx(n)
!$omp teams
!$omp distribute parallel do if(.false.)
do i=1,n
idx(i) = i
end do
!$omp end teams
print *, idx
end program
```
Key Instructions will start development behind a compile time flag to avoid
passing on the increased memory usage to all debug builds. We're working on
improving DILocation memory characteristics simultaneously; once that work lands
we can remove `EXPERIMENTAL_KEY_INSTRUCTIONS`.
This patch doesn't add any code, it's just so we can get the SIE buildbot
building with the new option right away.
While building llvm (clang, lld) against emscripten we see this
[error](https://github.com/emscripten-forge/recipes/actions/runs/13803029307/job/38608794602#step:9:1715)
```
│ │ In file included from $SRC_DIR/llvm/lib/Frontend/OpenACC/ACC.cpp:9:
│ │ $SRC_DIR/build/include/llvm/Frontend/OpenACC/ACC.h.inc:192:1: error: unknown type name 'LLVM_ABI'
│ │ 192 | LLVM_ABI Directive getOpenACCDirectiveKind(llvm::StringRef Str);
│ │ | ^
│ │ $SRC_DIR/build/include/llvm/Frontend/OpenACC/ACC.h.inc:192:19: error: expected ';' after top level declarator
│ │ 192 | LLVM_ABI Directive getOpenACCDirectiveKind(llvm::StringRef Str);
│ │ | ^
```
Now this was happening because we weren't defining LLVM_ABI correctly when building against emscripten. If you see [llvm/Support/Compiler.h](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/Compiler.h#L206-L210), the condition only checked for the platform __WASM__ . Now Emscripten targets WebAssembly but doesn't imply the platform by default so the check isn't complete to define LLVM_ABI.
The successful build after using this patch can be seen [here](https://github.com/emscripten-forge/recipes/actions/runs/13805214092/job/38614585621)
This commit updates the following operations (operands/results) to be of
at least rank 1 such that it aligns with the expectations of the
specification:
- ARGMAX (input)
- REDUCE_ALL (input/output)
- REDUCE_ANY (input/output)
- REDUCE_MAX (input/output)
- REDUCE_MIN (input/output)
- REDUCE_PRODUCT (input/output)
- REDUCE_SUM (input/output)
- CONCAT (each input in input1/output)
- PAD (input1/output)
- REVERSE (input1/output)
- SLICE (input1/output)
- TILE (input1/output)
- TRANSPOSE (input1/output)
In addition to this change, PAD has been updated to allow unranked
tensors for input1/output, inline with other operations.
In the static analyzer codebase we have a traditional pattern where a
single checker class (and its singleton instance) acts as the
implementation of several (user-facing or modeling) checkers that have
shared state and logic, but have their own names and can be enabled or
disabled separately.
Currently these multipart checker classes all reimplement the same
boilerplate logic to store the enabled/disabled state, the name and the
bug types associated with the checker parts. This commit extends
`CheckerBase`, `BugType` and the checker registration process to offer
an easy-to-use alternative to that boilerplate (which includes the ugly
lazy initialization of `mutable std::unique_ptr<BugType>`s).
In this new framework the single-part checkers are internally
represented as "multipart checkers with just one part" (because this way
I don't need to reimplement the same logic twice) but this does not
require any changes in the code of simple single-part checkers.
I do not claim that these multi-part checkers are perfect from an
architectural point of view; but they won't suddenly disappear after
many years of existence, so we might as well introduce a clear framework
for them. (Switching to e.g. 1:1 correspondence between checker classes
and checker names would be a prohibitively complex change.)
This PR ports `DivZeroChecker` to the new framework as a proof of
concept. I'm planning to do a series of follow-up commits to port the
rest of the multi-part checker.
