This patch aims to exploit the xxsplti32dx XT, IX, IMM32 instruction when lowering VECTOR_SHUFFLEs.
We implement lowerToXXSPLTI32DX when lowering vector shuffles to check if:
- Element size is 4 bytes
- The RHS is a constant vector (and constant splat of 4-bytes)
- The shuffle mask is a suitable mask for the XXSPLTI32DX instruction where it is one of the 32 masks:
<0, 4-7, 2, 4-7>
<4-7, 1, 4-7, 3>
Differential Revision: https://reviews.llvm.org/D83245
The use case is out of tree code deriving from this class - but without
a need to use the base class polymorphically, so skip the virtualization
and virtual dtor.
Post-commit review from 50ac7ce94f
X / (fabs(A) * sqrt(Z)) --> X / sqrt(A*A*Z) --> X * rsqrt(A*A*Z)
In the motivating case from PR46406:
https://bugs.llvm.org/show_bug.cgi?id=46406
...this is restoring the sequence that was originally in the source code.
We extracted a term from within the sqrt because we do not know in
instcombine whether a target will expand a sqrt call.
Note: we could say that the transform in IR should be restricted, but
that would not solve the problem if the source was originally in the
pattern shown here.
This is a gray area for fast-math-flag requirements. I think we should at
least check fast-math-flags on the fdiv and fmul because I view this
transform as 2 pieces: reassociate the fmul operands and form reciprocal
from the fdiv (as with the existing transform). We could argue that the
sqrt also needs FMF, but that was not required before, so we should change
that in a follow-up patch if that seems better.
We don't currently have a way to check that the target will produce a sqrt
or recip estimate without actually creating nodes (the APIs are SDValue
getSqrtEstimate() and SDValue getRecipEstimate()), so we clean up
speculatively created nodes if we are not able to create an estimate.
The x86 test with doubles verifies that we are not changing a test with
no estimate sequence.
Differential Revision: https://reviews.llvm.org/D82716
Summary:
Modifies the algorithm sort bench:
- shows sorting time per element, instead of sorting time per array.
This would make comparison between different sizes of arrays easier.
- adds std::pair benchmark cases.
- uses a large number of arrays to benchmark, instead of repeatedly sorting the same array.
* sorting the same array again and again would not show actual sorting performance over randomized data sets.
Reviewers: EricWF, #libc, mvels
Reviewed By: EricWF, #libc, mvels
Subscribers: mgrang, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D81770
This patch adds missing GOMP_5.0 loop entry points which incorporate
new non-monotonic default into entry point name. Since monotonic
schedules are a subset of nonmonotonic, it is acceptable to use
monotonic as the implementation. This patch simply has the nonmonotonic
(and possibly non-monontonic) versions of the loop entry points as
wrappers around the monotonic ones.
Differential Revision: https://reviews.llvm.org/D73922
Summary:
This would have been marginally useful to me during/for rG7ea46aee3670981827c04df89b2c3a1cbdc7561b.
With ongoing migration to representing assumes via operand bundles on the assume, this will be gradually more useful.
Reviewers: nickdesaulniers, diegotf, dblaikie, george.burgess.iv, jdoerfert, Tyker
Reviewed By: nickdesaulniers
Subscribers: hiraditya, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83177
Summary:
It is reasonably common to want to clone some call with different bundles.
Let's actually provide an interface to do that.
Reviewers: chandlerc, jdoerfert, dblaikie, nickdesaulniers
Reviewed By: nickdesaulniers
Subscribers: llvm-commits, hiraditya
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83248
This diff merges all options for llvm-install-name-tool under a single
function processLoadCommands. Also adds another test case for -add_rpath
option.
Test plan: make check-all
Reviewed by: jhenderson, alexshap, smeenai, Ktwu
Differential Revision: https://reviews.llvm.org/D82812
As reported in https://reviews.llvm.org/D83101#2133062
the new visitInsertElementInst()/visitExtractElementInst() functionality
is causing miscompiles (previously-crashing test added)
It is due to the fact how the infra of Scalarizer is dealing with DCE,
it was not updated or was it ready for such scalar value forwarding.
It always assumed that the moment we "scalarized" something,
it can go away, and did so with prejudice.
But that is no longer safe/okay to do.
Instead, let's prevent it from ever shooting itself into foot,
and let's just accumulate the instructions-to-be-deleted
in a vector, and collectively cleanup (those that are *actually* dead)
them all at the end.
All existing tests are not reporting any new garbage leftovers,
but maybe it's test coverage issue.
Instead of detecting the string in 2 places. Just swap the string
to 'sse4.1' or 'sse4.2' at the top of the function.
Prep work for a patch to switch the rest of this function to a
table based system. And I don't want to include 'sse4a' in the
table.
Even though wide vectors are legal they still cost more as we
will have to eventually split them. Not all operations can
be uniformly done on vector types.
Conservatively add the cost of splitting at least to 8 dwords,
which is our widest possible load.
We are more or less lying to cost mode with this change but
this can prevent vectorizer from creation of wide vectors which
results in RA problems for us.
Differential Revision: https://reviews.llvm.org/D83078
Currently APValues are dumped as a single string. This becomes quickly
completely unreadable since APValue is a tree-like structure. Even a simple
example is not pretty:
struct S { int arr[4]; float f; };
constexpr S s = { .arr = {1,2}, .f = 3.1415f };
// Struct fields: Array: Int: 1, Int: 2, 2 x Int: 0, Float: 3.141500e+00
With this patch this becomes:
-Struct
|-field: Array size=4
| |-elements: Int 1, Int 2
| `-filler: 2 x Int 0
`-field: Float 3.141500e+00
Additionally APValues are currently only dumped as part of visiting a
ConstantExpr. This patch also dump the value of the initializer of constexpr
variable declarations:
constexpr int foo(int a, int b) { return a + b - 42; }
constexpr int a = 1, b = 2;
constexpr int c = foo(a, b) > 0 ? foo(a, b) : foo(b, a);
// VarDecl 0x62100008aec8 <col:3, col:57> col:17 c 'const int' constexpr cinit
// |-value: Int -39
// `-ConditionalOperator 0x62100008b4d0 <col:21, col:57> 'int'
// <snip>
Do the above by moving the dump functions to TextNodeDumper which already has
the machinery to display trees. The cases APValue::LValue, APValue::MemberPointer
and APValue::AddrLabelDiff are left as they were before (unimplemented).
We try to display multiple elements on the same line if they are considered to
be "simple". This is to avoid wasting large amounts of vertical space in an
example like:
constexpr int arr[8] = {0,1,2,3,4,5,6,7};
// VarDecl 0x62100008bb78 <col:3, col:42> col:17 arr 'int const[8]' constexpr cinit
// |-value: Array size=8
// | |-elements: Int 0, Int 1, Int 2, Int 3
// | `-elements: Int 4, Int 5, Int 6, Int 7
Differential Revision: https://reviews.llvm.org/D83183
Reviewed By: aaron.ballman
The new option works like the existing LLVM_TABLEGEN, and
LLVM_CONFIG_PATH options. Instead of building llvm-nm, the build uses
the executable defined by LLVM_NM.
This is useful for cross-compilation scenarios where the host cannot run
the cross-compiled tool, and recursing into another cmake build is not
an option (due to required DEFINE's, for example).
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D83022
Summary:
Aside from unifying the code a bit, this change smooths the
transition to use of future "opaque generic block references"
in the type-erased dominator tree base class.
Change-Id: If924b092cc8561c4b6a7450fe79bc96df0e12472
Reviewers: arsenm, RKSimon, mehdi_amini, courbet
Subscribers: wdng, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83086
Summary:
Avoid exposing details about how roots are stored. This enables subsequent
type-erasure changes.
v5:
- cleanup a unit test by using EXPECT_EQ instead of EXPECT_TRUE
Change-Id: I532b774cc71f2224e543bc7d79131d97f63f093d
Reviewers: arsenm, RKSimon, mehdi_amini, courbet
Subscribers: jvesely, wdng, hiraditya, kuhar, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83085
Summary:
Avoid exposing details about how children are stored. This will enable
subsequent type-erasure changes.
New methods are introduced to cover common access patterns.
Change-Id: Idb5f4b1b9c84e4cc71ddb39bb52a388682f5674f
Reviewers: arsenm, RKSimon, mehdi_amini, courbet
Subscribers: qcolombet, sdardis, wdng, hiraditya, jrtc27, zzheng, atanasyan, asbirlea, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83083
This covers both the existing memory functions as well as the new bulk memory proposal.
Added new test files since changes where also required in the inputs.
Also removes unused init/drop intrinsics rather than trying to make them work for 64-bit.
Differential Revision: https://reviews.llvm.org/D82821
Summary:
Change MCExpr to support Aurora VE's modifiers. Change asmparser to use
existing MCExpr parser (parseExpression) to parse an expression contining
symbols with modifiers and offsets. Also add several regression tests
of MC layer.
Reviewers: simoll, k-ishizaka
Reviewed By: simoll
Subscribers: hiraditya, llvm-commits
Tags: #llvm, #ve
Differential Revision: https://reviews.llvm.org/D83170
The Swift symbol name prefix has changed from `_T0` to `_$s` as
documented here [1]. This prevents Swift names from properly being
symbolicated when using the in-process LLVM symbolizer. The best way to
fix this seems to be to avoid the duplication of "Is this a Swift symbol
name?" here. We can simply remove this check as `swift_demangle`
already returns null for non-Swift names [2,3].
The check was included in the initial support for Swift name demangling
to avoid superfluous calls to `dlsym()` [4]. A subsequent commit
changed this logic to retrieve the `swift_demangle` function pointer
eagerly during sanitizer initialization, but did not remove the check
[5].
[1] https://github.com/apple/swift/blob/master/docs/ABI/Mangling.rst
[2] b5a8b518ea/include/swift/Demangling/Demangle.h (L643)
[3] b5a8b518ea/stdlib/public/runtime/Demangle.cpp (L656)
[4] https://reviews.llvm.org/D19135
[5] https://reviews.llvm.org/D20015
rdar://62753845
Reviewers: kubamracek, delcypher, dcoughlin, samsonov, thakis
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D81705
The Symbol Table in LLD references the global object to add a symbol rather than adding it to itself.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D83184
Summary: Change to use isa instead of dyn_cast to avoid a warning.
Reviewers: simoll, k-ishizaka
Reviewed By: simoll
Subscribers: hiraditya, llvm-commits
Tags: #llvm, #ve
Differential Revision: https://reviews.llvm.org/D83200
Mark these tests as only failing on PowerPC. Avoids unexpected passes on
other bots.
Fingers crossed.
Differential Revision: https://reviews.llvm.org/D80952
This was resulting in a missing vreg def in the use select
instruction.
The output of the pseudo doesn't make sense, since it really shouldn't
have the vreg output in the first place, and instead an implicit scc
def to match the real scalar behavior.
We could have easier to understand tests if we selected scalar
versions of the [us]{add|sub}.with.overflow intrinsics.
This does still end up producing vector code in the end, since it gets
moved later.
Summary:
A program may erroneously reference the same name as both a data object
and as a function. Some of these references were causing an internal
error in expression analysis.
It was already the case that a symbol referenced in a parse tree for a
call was changed from an `Entity` to a `ProcEntity`. I added code to
detect when a symbol was referenced in a parse tree as an array element
gets changed from an `Entity` to an `ObjectEntity`. Then, if an
`ObjectEntity` gets called as a function or a `ProcEntity` gets
referenced as a data object, errors get emitted.
This analysis was previously confined to the name resolution of the
specification part of a `ProgramTree`. I added a pass to the execution
part of a `ProgramTree` to catch names declared in blocks.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D82903
Summary:
Some libraries use empty function to ignore unused variable warnings, which gets a new warning from `-Wuninitialized-const-reference`, discussed here https://reviews.llvm.org/D79895#2107604.
This patch should fix that.
Reviewers: hans, nick, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: aaron.ballman, riccibruno, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82425
Add new unit tests for external Fortran I/O that drive the
Fortran I/O runtime API from C++ and exercise basic writing
and read-back in the various combinations of access modes,
record length variability, and formatting. Sequential modes
are tested with positioning. More thorough tests written in
Fortran will follow when they can be compiled and run.
The Fortran runtime's error termination callback registration
was extended with source file and line number positions for
better failure messages in unit testing.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D83164
We currently have strict floating point/constrained floating point enabled
for all targets. Constrained SDAG nodes get converted to the regular ones
before reaching the target layer. In theory this should be fine.
However, the changes are exposed to users through multiple clang options
already in use in the field, and the changes are _completely_ _untested_
on almost all of our targets. Bugs have already been found, like
"https://bugs.llvm.org/show_bug.cgi?id=45274".
This patch disables constrained floating point options in clang everywhere
except X86 and SystemZ. A warning will be printed when this happens.
Differential Revision: https://reviews.llvm.org/D80952
Amy Kwan