This was missing a call to `ignoreCFGOmittedNodes()`. As a result, the
function
would erroneously conclude that a block did not contain an expression
consumed
in a different block if the expression in question was surrounded by a
`ParenExpr` in the consuming block. The patch adds a test that triggers
this
scenario (and fails without the fix).
To prevent this kind of bug in the future, the patch also adds a new
method
`blockForStmt()` to `AdornedCFG` that calls `ignoreCFGOmittedNodes()`
and is
preferred over accessing `getStmtToBlock()` directly.
Flang-new needs to add `mlink-builtin-bitcode` objects to properly
support offload code generation for AMD GPUs (for example, math
functions).
Both Flang-new and Clang rely on `mlink-builtin-bitcode` flags. These
flags are added by the `AMDGPUOpenMPToolchain::addClangTargetOptions`
function. Now, both compilers reuse the same function.
Flang-new tests for AMDGPU were updated by adding the `-nogpulib` flag.
This flag allows running AMDGPU tests on machines without the ROCm stack.
Depends on https://github.com/llvm/llvm-project/pull/100674
Currently, we treat VLAs declared as `int[]` and `int[0]` identically.
I.e., we create them as `IncompleteArrayType`s. However, the
`DW_AT_count` for `int[0]` *does* exist, and is retrievable without an
execution context. This patch decouples the notion of "has 0 elements"
from "has no known `DW_AT_count`".
This aligns with how Clang represents `int[0]` in the AST (it treats it
as a `ConstantArrayType` of 0 size).
This issue was surfaced when adapting LLDB to
https://github.com/llvm/llvm-project/issues/93069. There, the
`__compressed_pair_padding` type has a `char[0]` member. If we
previously got the `__compressed_pair_padding` out of a module (where
clang represents `char[0]` as a `ConstantArrayType`), and try to merge
the AST with one we got from DWARF (where LLDB used to represent
`char[0]` as an `IncompleteArrayType`), the AST structural equivalence
check fails, resulting in silent ASTImporter failures. This manifested
in a failure in `TestNonModuleTypeSeparation.py`.
**Implementation**
1. Adjust `ParseChildArrayInfo` to store the element counts of each VLA
dimension as an `optional<uint64_t>`, instead of a regular `uint64_t`.
So when we pass this down to `CreateArrayType`, we have a better
heuristic for what is an `IncompleteArrayType`.
2. In `TypeSystemClang::GetBitSize`, if we encounter a
`ConstantArrayType` simply return the size that it was created with. If
we couldn't determine the authoritative bound from DWARF during parsing,
we would've created an `IncompleteArrayType`. This ensures that
`GetBitSize` on arrays with `DW_AT_count 0x0` returns `0` (whereas
previously it would've returned a `std::nullopt`, causing that
`FieldDecl` to just get dropped during printing)
PR #77936 introduced a diagnostic to avoid calls being inlined into
functions with a different streaming mode, because inlining those
functions may result in different runtime behaviour. This was necessary
because LLVM doesn't check whether inlining is possible and thus blindly
inlines the function without checking feasibility.
In practice however, this introduces an artificial restriction that the
user may not be able to work around. Calling an `always_inline` function
from some header file that is out of the control of the user would
result in an error that the user cannot remedy.
Therefore, this patch demotes the error into a warning (for calls from
streaming[-compatible] -> non-streaming), but the proper fix would be to
fix the AlwaysInliner in LLVM to avoid inlining when it has analyzed the
callee and has determined that inlining is not possible.
Calling an always_inline function for calls from non-streaming ->
streaming will remain an error, because there is little pre-existing
code for SME, so it is expected that the header file can be modified by
the user (e.g. by using `__arm_streaming_compatible` if the code is
claimed to be compatible).
This reverts commit 88e5206f2c96a34e23a4d63f0a38afb2db044f0a. The
original change went in a while ago (last year) in
https://reviews.llvm.org/D145057. The specific reason I'm proposing a
revert is that this is now causing exactly the issue that @balazske
predicted in https://reviews.llvm.org/D145057#4164717:
> Problematic case is if the attribute has pointer to a Decl or Type
that is imported here in a state when the field is already created but
not initialized. Another problem is that attributes are added a second
time in Import(Decl *)
This now came up in the testing of LLDB support for
https://github.com/llvm/llvm-project/issues/93069. There,
`__compressed_pair`s are now replaced with fields that have an
`alignof(...)` and `[[no_unique_address]]` attribute. In the specific
failing case, we're importing following `std::list` method:
```
size_type& __sz() _NOEXCEPT { return __size_; }
```
During this process, we create a new `__size_` `FieldDecl` (but don't
initialize it yet). Then we go down the `ImportAttrs` codepath added in
D145057. This imports the `alignof` expression which then references the
uninitialized `__size_` and we trigger an assertion.
Important to note, this codepath was added specifically to support
`[[no_unique_address]]` in LLDB, and was supposed to land with
https://reviews.llvm.org/D143347. But the LLDB side of that never
landed, and the way we plan to support `[[no_unique_address]]` doesn't
require things like the `markEmpty` method added here. So really, this
is a dead codepath, which as pointed out in the original review isn't
fully sound.
Currently we would unconditionally add an implicit `this` parameter when
creating an instance method type. However, when we have an explicit
'this', we shouldn't generate one. This patch only passes a valid
`ThisPtr` type to `getOrCreateInstanceMethodType` if one wasn't
explicitly specified. There's no way to get a pointer to a member
function with an explicit `this` parameter (those are treated as regular
function pointers instead). So there's no need to account for that case
in `CGDebugInfo::CreateType`.
Fixes https://github.com/llvm/llvm-project/issues/99744
This patch ports the commit a6614ec5b7c1dbfc4b847884c5de780cf75e8e9c to
SelectionDAG TypeLegalization.
Fixes#98044
Co-authored-by: Manish Kausik H <hmamishkausik@gmail.com>
As detailed in Issue #100320, a considerable number of tests that
explicitly use `-fuse-ld=lld` `FAIL` on Linux/sparc64 due to several
`lld` limitations (no 32-bit SPARC support, lack of support for various
relocations, ...).
To reduce the noise, this patch disables `COMPILER_RT_HAS_LLD` on SPARC
wholesale.
Tested on `sparc64-unknown-linux-gnu`.
Fix the false negative caused by state merging in the evaluation of a
short-circuiting expression inside the condition of a ternary operator.
The fixed symptom is that CSA always evaluates `(x || x) ? n : m` to
`m`.
This change forces the analyzer to consider all logical expressions
prone to short-circuiting alive until the entire conditional expression
is evaluated. Here is why.
By default, LiveVariables analysis marks only direct subexpressions as
live relative to any expression. So for `a ? b : c` it will consider
`a`, `b`, and `c` alive when evaluating the ternary operator expression.
To explore both possibilities opened by a ternary operator, it is
important to keep something different about the exploded nodes created
after the evaluation of its branches. These two nodes come to the same
location, so they must have different states. Otherwise, they will be
considered identical and can engender only one outcome.
`ExprEngine::visitGuardedExpr` chooses the first predecessor exploded
node to carry the value of the conditional expression. It works well in
the case of a simple condition, because when `a ? b : c` is evaluated,
`a` is kept alive, so the two branches differ in the value of `a`.
However, before this patch is applied, this strategy breaks for `(x ||
x) ? n : m`. `x` is not a direct child of the ternary expression. Due to
short-circuiting, once `x` is assumed to be `true`, evaluation jumps
directly to `n` and then to the result of the entire ternary expression.
Given that the result of the entire condition `(x || x)` is not
constructed, and `x` is not kept alive, the difference between the path
coming through `n` and through `m` disappears. As a result, exploded
nodes coming from the "true expression" and the "false expression"
engender identical successors and merge the execution paths.
Previous commit uses wrong clock id and forget to release an additional
rdlock. cc @Eric977
Sorry for missing this in my initial review.
Fixes https://github.com/llvm/llvm-project/issues/100960.
Notice that the timestamp is created via
```c++
LIBC_NAMESPACE::clock_gettime(CLOCK_REALTIME, &ts);
ts.tv_nsec += 50'000;
if (ts.tv_nsec >= 1'000'000'000) {
ts.tv_nsec -= 1'000'000'000;
ts.tv_sec += 1;
}
```
The grouped vector register is modeled as a single register, e.g. V2M2,
which is actually V2 and V3. We need to decompose the grouped vector
register(if any) to individual vector register when emitting CFIs in
prologue.
Fixed https://github.com/llvm/llvm-project/issues/94500
This change is part 2 x86 Loop Vectorization of :
https://github.com/llvm/llvm-project/pull/96222
It also has veclib call loop vectorization hence the test cases in
`llvm/test/Transforms/LoopVectorize/X86/veclib-calls.ll`
finally the last pr missed tests for
`llvm/test/CodeGen/X86/fp-strict-libcalls-msvc32.ll` and
`llvm/test/CodeGen/X86/vec-libcalls.ll` so added those aswell.
No evidence was found for arc and hyperbolic trig glibc vector math
functions
https://github.com/lattera/glibc/blob/master/sysdeps/x86/fpu/bits/math-vector.h
so no new `_ZGVbN2v_*` and `_ZGVdN4v_*` .
So no new tests in
`llvm/test/Transforms/LoopVectorize/X86/libm-vector-calls-VF2-VF8.ll`
Also no new svml and no new tests to:
`llvm/test/Transforms/LoopVectorize/X86/svml-calls.ll`
There was not enough evidence that there were svml arc and hyperbolic
trig vector implementations, Documentation was scarces so looked at test
cases in
[numpy](32bf2a9842/linux/avx512/svml_z0_acos_d_la.s (L8)).
Someone with more experience with svml should investigate.
## Note
amd libm doesn't have a vector hyperbolic sine api hence why youi might
notice there are no tests for `sinh`.
## History
This change is part of
https://github.com/llvm/llvm-project/issues/87367's investigation on
supporting IEEE math operations as intrinsics.
Which was discussed in this RFC:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294
This change adds loop vectorization for `acos`, `asin`, `atan`, `cosh`,
`sinh`, and `tanh`.
resolves#70079resolves#70080resolves#70081resolves#70083resolves#70084resolves#95966
After #98505, the textual IR keyword `x86_mmx` was temporarily made to
parse as `<1 x i64>`, so as not to require a lot of test update noise.
This completes the removal of the type, by removing the`x86_mmx` keyword
from the IR parser, and making the (now no-op) test updates via `sed -i
's/\bx86_mmx\b/<1 x i64>/g' $(git grep -l x86_mmx llvm/test/)`.
Resulting bitcasts from <1 x i64> to itself were then manually deleted.
Changes to llvm/test/Bitcode/compatibility-$VERSION.ll were reverted, as
they're intended to be equivalent to the .bc file, if parsed by old
LLVM, so shouldn't be updated.
A few tests were removed, as they're no longer testing anything, in the
following files:
- llvm/test/Transforms/GlobalOpt/x86_mmx_load.ll
- llvm/test/Transforms/InstCombine/cast.ll
- llvm/test/Transforms/InstSimplify/ConstProp/gep-zeroinit-vector.ll
Works towards issue #98272.
The 4 inline elements only cover 58% of cases encountered here during
the compilation of X86ISelLowering.cpp.ll, a .ll version of
X86ISelLowering.cpp.
The 8 inline elements cover 96% and save 0.27% of heap allocations.
If an included script is under the sysroot directory, when it opens an
absolute path file (`INPUT` or `GROUP`), add sysroot before the absolute
path. When the included script ends, the `isUnderSysroot` state is
restored.
FNV, used by stable_hash_combine_string is extremely slow. For string
hashing with good avalanche effects, we prefer xxh3_64bits.
StableHashing.h might still be useful as it provides a stable
hash_combine while Hashing.h's might be non-deterministic (#96282).
Pull Request: https://github.com/llvm/llvm-project/pull/100668
We ended up having two transformTemplateParameter() after CTAD for type
aliases was landed. This patch cleans them up and allows them to share
one implementation.
As a bonus, this also uses getDepthAndIndex() in preference to
getTemplateParameter{Depth,Index}().
When clang compiles the following expression:
```c++
return A{B{"Move Ctor"}};
```
(where `B` is a base class for `A`), it adds a call to the move
constructor of `B`. When the code is changed to...
```c++
return A{{"No Move Ctor"}};
```
... a move constructor is invoked neither for `A` nor for `B`.
The lit test demonstrates the difference in the generated AST.
In #96293 ("Remove superfluous sxtw in peephole opt") a file
`peephole-sxtw.mir` was added to `llvm/lib/Target/AArch64/`, but it
looks like this is a regression test file.
Move it to `llvm/test/CodeGen/AArch64/` which seems a more correct
location.
The polymorphic_allocator was added in C++17.
This issue was filed in 2022 so well after C++20. This issue adds an
operator==.
Starting with C++20 this adds a compiler generated operator!=. To have
the same behaviour in C++17 and C++20 (and later) a manual operator!= is
defined in C++17.
Implements
- LWG3683 operator== for polymorphic_allocator cannot deduce template
argument in common cases
Most of these bring the costs in line with the code generation. The f16 costs
without FullFP16 are usually converted to f32. Extended v2f32->v2f64 vectors
similarly use fcvtl + fcvt. As a backup we use the costs similar to the target
independent code, which should give a relatively high cost.
If we produce illegal v8f32 types, the VectorLegalizer will unroll them,
scalarizing the operations. In this patch we pre-split them during custom
legalization to produce better results.
The use of SmallVector here saves 1.03% of heap allocations during the
compilation of X86ISelLowering.cpp.ll, a .ll version of
X86ISelLowering.cpp. The 8 inline elements cover greater than 99% of
invocations encountered here.
While I am it, the patch changes the parameter type to ArrayRef to
allow callers to use any vector type.
