Given the same branch condition in `a` and `c` SimplifyCFG converts:
+> b -+
| v
--> a --> c --> e -->
| ^
+> d -+
into:
+--> bcd ---+
| v
--> a --> c --> e -->
Remap source atoms on instructions duplicated from `c` into `bcd`.
SimplifyCFG folds `b` into `a`.
+-----------+
| v
--> a --> b --> c --> d -->
| ^
+-----------------+
Remap source atoms in `b` so that the duplicated instructions are analysed
independently to determine is_stmt positions. This is necessary as the
contents of `b` may be folded into multiple preds in this way.
Add multi-pred test.
NFC for builds with LLVM_EXPERIMENTAL_KEY_INSTRUCTIONS=OFF (default).
In an ideal world we would be able to track that the merged location is used in
multiple source atoms. We can't do this though, so instead we arbitrarily but
deterministically pick one.
In cases where the InlinedAt field is unchanged we keep the atom with the
lowest non-zero rank (highest precedence). If the ranks are equal we choose
the smaller non-zero group number (arbitrary choice).
In cases where the InlinedAt field is adjusted we generate a new atom group.
Keeping the group wouldn't make sense (a source atom is identified by the
group number and InlinedAt pair) but discarding the atom info could result
in missed is_stmts.
Add unittest in MetadataTest.cpp.
Add:
mapAtomInstance - map the atom group number to a new group.
RemapSourceAtom - apply the mapped atom group number to this instruction.
Modify:
CloneBasicBlock - Call mapAtomInstance on cloned instruction's DebugLocs
if MapAtoms is true (default). Setting to false could
lead to a degraded debugging experience. See code comment.
Optimisations like loop unroll that duplicate instructions need to remap source
atom groups so that each duplicated source construct instance is considered
distinct when determining is_stmt locations.
This commit adds the remapping functionality and a unittest.
The definition EXPERIMENTAL_KEY_INSTRUCTIONS is controlled by cmake flag
LLVM_EXPERIMENTAL_KEY_INSTRUCTIONS.
Add IR read-write roundtrip test in a directory that is unsupported unless
the CMake flag is enabled.
In undefined mismatch cases, this was fixing the callsite to use the calling
convention of the new function. Preserve the original wrong callsite's calling
convention.
The attribute APIs make this cumbersome. There seem to be missing
overloads using AttrBuilder for the function attrs. Plus there doesn't
seem to be a direct way to set the function attrs on the call.
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.
