Partial progress towards removing in-tree uses of `getPointerTo()`,
by employing the following options:
* Drop the call entirely if the sole purpose of it is to support a no-op
bitcast (remove the no-op bitcast as well).
* Replace with `PointerType::get()`/`PointerType::getUnqual()`
This is a NFC cleanup effort.
Reviewed By: barannikov88
Differential Revision: https://reviews.llvm.org/D155232
The ORE argument threaded through ValueTracking is used only in a
single, untested place. It is also essentially never passed: The
only places that do so have been added very recently as part of the
KnownFPClass migration, which is vanishingly unlikely to hit this
code path. Remove this effectively dead argument.
Differential Revision: https://reviews.llvm.org/D151562
Loads can share dependencies, and moving them for each load separately
can end up placing them in a wrong location. There was already a check
for that, but it wasn't correct.
Instead of trying to find the right location for all moved instructions
at once, create clones for each individual load.
Generate a predicated variant of the last load/store in a group to
avoid accessing OOB memory. Disable vector alignment on HVX prior
to v62, since v62 does not have predicated vector loads.
The unused declaration was introduced without a corresponding function
definition in:
commit f5d07a05bbd41f827ccfa1bed7bfdfbab2be85dc
Author: Krzysztof Parzyszek <kparzysz@quicinc.com>
Date: Mon Sep 7 14:26:48 2020 -0500
value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
This fixes clang.
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Vector alignment code was grouping all aligned loads together. In some
cases the groups could become quite large causing a lot of spill to be
generated. This will place the loads closer to where they are used,
reducing the register pressure.
This patch fixes:
llvm/lib/Target/Hexagon/HexagonVectorCombine.cpp:1554:6: warning:
‘llvm::Value*
{anonymous}::HexagonVectorCombine::simplify(llvm::Value*) const’
defined but not used [-Wunused-function]
It can produce some dead code, which is harmless in the end, but breaks
expensive checks when unreported. This should be fixed eventually, but
it's a low priority.
This will allow recognizing Q.31 multiplications on vectors that are
multiplies of HVX vectors. At the moment this comes at the expense of
Q.15 multiplications, which now are handled as 32-bit multiplications
with shifts.
In the longer term this will likely be replaced by a different scheme
of "legalizing" vectors, which is necessary for idiom recognition, at
least where using direct HVX instrinsics is desired.
HVC::calculatePointerDifference inserts temporary instructions for
simplification, and calulation of known bits. These instructions were
inserted at the end of a basic block (after the terminator), which
caused BB->getTerminator() to return nullptr. This, in turn, caused
a crash when a PHI instruction was examined in computeKnownBits.
This should fix
```
Pass modifies its input and doesn't report it: Hexagon Vector Combine
Pass modifies its input and doesn't report it UNREACHABLE executed at
[...hecks-debian/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1436!
```
There are intrinsics for most scalar instructions and almost all HVX
instructions. What's somewhat painful is that there are two intrinsics
for each HVX instruction: one for 64- and one for 128-byte mode.
Instead of checking the current codegen settings every time, this
function would simply return the right intrinsic.
1. `length(value/type)`: return the number of elements in the vector
input,
2. `getHvxTy(elem_type)`: return the HVX vector type with the element
type provided.
These will help write things more succintly.
