This adds new types and helpers to support the 'initialize' request with
the new typed RequestHandler. While working on this I found there were a
few cases where we incorrectly treated initialize arguments as
capabilities. The new `lldb_dap::protocol::InitializeRequestArguments`
and `lldb_dap::protocol::Capabilities` uncovered the inconsistencies.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
We already had a template isUImm function. This patch adds isSImm,
isShiftedUImm, and 2 helpers that take a predicate function to validate
the immediate with. I'm using a template for the predicate function.
As with #132002, these do show up in a compilation of llvm-test-suite
(including SPEC 2017). We remove 30-40 static instances so this isn't
anything earth shattering.
rs2 is always added to the other shifted (and potentially extended)
operand unmodified, so rs1==zero is equivalent to a copy.
Set it to true only if isInt<16>.
By default implemention defines them to true always. For most cases,
MIPS uses 16bit IMM, and for microMIPS, ICMP and ADDiu have 16bit IMM
flavors.
Optimize the IR generated for a VPWidenIntOrFpInductionRecipe to use the
narrowest type necessary, when the trip-count of a loop is known to be
constant and the only use of the recipe is the condition used by the
vector loop's backedge branch.
clang-19 changed how Arm triples were normalised and so while we
supported 18 and 19, we could not hard code the path here.
Now that Linaro's bots are running clang-19, and libcxx is going to drop
clang-18 support (https://github.com/llvm/llvm-project/pull/130142) I
have simplified it by hard coding the path again.
I also looked into why this exists in the first place. It was added in
https://reviews.llvm.org/D154246 but not questioned at the time.
It is due to the way we build compiler-rt, which is due to the final
layout we need in the install:
1. The builtins library must be called libclang_rt.builtins.a for clang
to find it. There must not be an architecture name in the filename.
2. That builtins library must be directly in lib/, next to picolib's
installed files.
To achieve number 1 we must set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON.
However, that causes the file to be installed in a per-target dir which
breaks number 2. So to fix that, we move the builtins library up one
level into lib/.
The alternative is to turn off per-target dirs, which results in a
builtin file with an arch in the name, then rename and move that file
(since it gets installed into lib/generic/).
So in the end, it's the same amount of hacks. I think it's best to keep
the one that uses LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON, as this is the
recommended way to built these days.
This is a follow up to #133171. I realized we could assume the structure
of the previous MMO, and thus the split is much simpler than I'd
initially pictured.
I would like to nominate Mario Cupelli (@mariocup) and myself to join
the LLVM Security Group as representatives (vendor contacts) of [HighTec
EDV Systeme](https://github.com/hightec-rt).
Mario is the CTO of HighTec and has a strong background in compiler
safety qualification. I am a SW engineer with a focus on cybersecurity
and a goal to contribute to the LLVM Security Group.
HighTec collaborates with major silicon vendors and offers
safety-qualified C/C++ and Rust compilers based on LLVM. Our active
contributions to LLVM include work on the linker and various patches and
we are committed to further improving LLVM’s security.
Our motivation for joining the LLVM Security Group is to collaborate
with LLVM security experts, stay informed about the latest CVEs in LLVM
and meet the cybersecurity requirements of the automotive industry.
Improve docs for `bugprone-argument-comment` check by writing explicitly
default values for options.
Before this change, it was unclear what values are default.
In the wake of discussion in PR #131200 and internal discussion after,
we will add support for `LLVM_ENABLE_PER_TARGET_RUNTIME=ON` for AIX
instead of disable it. I already reverted the change in PR #131200.
The default value of the option is still OFF on AIX.
This commit adds an additional overload to `replaceOpWithMultiple` that
accepts additional container types. This has been brought up by users of
the new `replaceOpWithMultiple` API.
In particular, one missing container type was
`SmallVector<SmallVector<Value>>`. The "default" `ArrayRef<ValueRange>`
container type can lead to use-after-scope errors in cases such as:
```c++
// Compute the replacement value ranges. Some replacements are single
// values, some are value ranges.
SmallVector<ValueRange> repl;
repl.push_back(someValueRange); // OK
for (...) {
// push_back(Value) triggers an implicit conversion to ValueRange,
// which does not own the range.
repl.push_back(someValue); // triggers use-after-scope later
}
rewriter.replaceOpWithMultiple(op, repl);
```
In this example, users should use `SmallVector<SmallVector<Value>>
repl;`.
Currently there are two specific overloads: for unary operations, i.e.
`Operation<D, R, O>`, and binary ones `Operation<D, R, LO, RO>`.
This makes it impossible for a derived class to use a single overload to
handle all types of operations: `Operation<D, R, O...>`. Since the base
overloads need to be included in the derived class's scope, via `using
Base::operator()` either one of the specific overloads will always be a
better candidate than the more generic derived one.
```
class MyVisitor : public Traverse<...> {
using Traverse<...>::operator();
template <typename D, typename R, typename... O>
Result operator()(const Operation<D, R, O...> &op) const {
// Will never be used.
}
};
```
This patch replaces the two specific overloads for Operation in Traverse
with a single generic overload, while preserving the existing
functionality, and allowing derived classes to use a single overload as
well.
This adds coverage for additional instructions in isCopyInstrImpl, for
now picking just those where I can observe that there is a codegen
difference for SPEC.
This allows MachineCopyPropagation to successfully eliminate no-op moves in this form.
Summary:
When we were first porting to COV5, this lead to some ABI issues due to
a change in how we looked up the work group size. Bitcode libraries
relied on the builtins to emit code, but this was changed between
versions. This prevented the bitcode libraries, like OpenMP or libc,
from being used for both COV4 and COV5. The solution was to have this
'none' functionality which effectively emitted code that branched off of
a global to resolve to either version.
This isn't a great solution because it forced every TU to have this
variable in it. The patch in
https://github.com/llvm/llvm-project/pull/131033 removed support for
COV4 from OpenMP, which was the only consumer of this functionality.
Other users like HIP and OpenCL did not use this because they linked the
ROCm Device Library directly which has its own handling (The name was
borrowed from it after all).
So, now that we don't need to worry about backward compatibility with
COV4, we can remove this special handling. Users can still emit COV4
code, this simply removes the special handling used to make the OpenMP
device runtime bitcode version agnostic.
Fixes#133344
Proof: https://alive2.llvm.org/ce/z/X3Uh23
InstCombine couldn't optimize `i1` because `canonicalizeICmpBool()` was
transforming the comparison into bitwise operations before
`foldICmpTruncWithTruncOrExt()` was called.
This PR solves the ordering issue by placing
`foldICmpTruncWithTruncOrExt()` before `canonicalizeICmpBool()`.
I believe this will not cause any regressions since all tests are
passing.
.enable lowers to Unroll LoopControl
.disable lowers to DontUnroll LoopControl
.count lowers to PartialCount LoopControl
.full lowers to Unroll LoopControl
TODO in future patches: enable structurizer for non-vulkan targets.
---------
Signed-off-by: Sidorov, Dmitry <dmitry.sidorov@intel.com>
After https://github.com/llvm/llvm-project/pull/130605
structurizer/cf.switch.ifstmt.simple2.ll test case starts failing with
the "PHI operand is not live-out from predecessor" diagnostic message.
This test case didn't include usual "-verify-machineinstrs" argument and
the fail was missed before
https://github.com/llvm/llvm-project/pull/130605 merging.
The problem looks not blocking, because the test case successfully
passes its CHECK's. This PR is to fix the build process by mark the test
case as XFAIL when LLVM_ENABLE_EXPENSIVE_CHECKS is enabled.
Investigation of the Machine Verifier complaint is to do. The issue is
created: https://github.com/llvm/llvm-project/issues/133141
When retrieving the ExplicitSpecifier from a CXXConstructorDecl, one of
its canonical declarations is returned. To correctly write the
declaration record the ExplicitSpecifier of the current declaration must
be used.
Failing to do so results in a crash during deserialization.
Added pattern so s_nor is selected for ((i1 x or i1 y) xor -1) instead
of s_or and s_xor . This patch is for i1 divergent. The ballot in the
test is added for the retrieval of lanemask. The control flow is needed
because the combiner can't pass through phi instructions.
When building with asserts enabled, this can actually cause strange
miscompilations because an incorrect llvm.assume is generated at the
point of the assertion.
Previously `optin.taint.GenericTaint` misinterpreted the parameter
indices and produced false positives in situations when a [format
attribute](https://clang.llvm.org/docs/AttributeReference.html#format)
is applied on a non-static method. This commit fixes this bug
Relands #132907 with a fix in the testcase:
clang/test/CodeGen/Mips/subtarget-feature-test.c
enable this test for only mips64 target
PR #130587 defined same SubTargetFeature for CPUs i6400 and i6500 which
resulted into following warning when -mcpu=i6500 was used:
+i6500' is not a recognized feature for this target (ignoring feature)
This PR fixes above issue by defining separate SubTargetFeature for
i6500.
Add a new VPIRPhi subclass of VPIRInstruction, that purely serves as an
overlay, to provide more convenient checking (via directly doing
isa/dyn_cast/cast) and specialied execute/print implementations.
Both VPIRInstruction and VPIRPhi share the same VPDefID, and are
differentiated by the backing IR instruction.
This pattern could alos be used to provide more specialized interfaces
for some VPInstructions ocpodes, without introducing new, completely
spearate recipes. An example would be modeling VPWidenPHIRecipe &
VPScalarPHIRecip using VPInstructions opcodes and providing an interface
to retrieve incoming blocks and values through a VPInstruction subclass
similar to VPIRPhi.
PR: https://github.com/llvm/llvm-project/pull/129387
The format is: `!instances<T>([regex])`.
This operator produces a list of records whose type is `T`. If
`regex` is provided, only records whose name matches the regular
expression `regex` will be included. The format of `regex` is ERE
(Extended POSIX Regular Expressions).
