The exception model now comes only from the "exception-model" module
flag. Remove the TargetOptions field and its copy into MCAsmInfo, so
MCAsmInfo only knows the target's default model.
The WebAssembly model checks move from the TargetMachine constructor
into the Emscripten EH/SjLj lowering pass. Clang relied on the backend
to reject non-wasm models for wasm targets, so it now rejects them itself.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
For a register class and one sub-register index, the register info
emitter generates a bit mask with a bit set for every class whose
registers have that sub-register in this class. A class gets one mask
for each sub-register index for which such classes exist. These masks
were stored in the SubClassMasks array right after the class's sub-class
mask and read by striding from it, so the position of a mask determined
which class and sub-register index it belonged to. Identical masks of
different classes and sub-register indices therefore could not be
shared. AMDGPU has 15,145 such masks, only 1,035 of them distinct, and
one is repeated 370 times.
This patch emits each distinct mask once, into a pool that follows the
sub-class masks in the SubClassMasks array, and gives each class an
array of offsets into that pool, one per mask. The offsets are relative
to the MCRegisterClass object, which is the convention SubClassMaskOff
and SuperRegIndicesOff already use, so the storage remains a constant
initializer that needs no relocations.
The size of <Target>MCRegisterClassStorage, in bytes:
before after saved
AMDGPU 2,446,208 870,032 1,576,176 64.4%
AArch64 105,568 86,152 19,416 18.4%
ARM 27,432 21,400 6,032 22.0%
RISCV 26,088 23,960 2,128 8.2%
X86 20,392 19,848 544 2.7%
PPC 8,528 8,256 272 3.2%
Mips 9,088 9,080 8 0.1%
Lanai 328 328 0
MSP430 224 224 0
SPIRV 728 728 0
XCore 208 208 0
LoongArch 1,344 1,352 -8 -0.6%
NVPTX 640 648 -8 -1.2%
WebAssembly 584 592 -8 -1.4%
BPF 200 208 -8 -4.0%
DirectX 80 88 -8 -10.0%
R600 9,464 9,480 -16 -0.2%
VE 1,504 1,520 -16 -1.1%
AVR 3,840 3,872 -32 -0.8%
Sparc 2,216 2,248 -32 -1.4%
Hexagon 3,344 3,392 -48 -1.4%
SystemZ 2,856 2,904 -48 -1.7%
Some targets grow, by at most 48 bytes. They have few enough
super-register indices that the offsets cost more than the shared masks
save. The ones that lose 8 bytes have no identical masks at all, so they
only pay for the offsets array, which has one element even when a target
needs none.
MCRegisterClass exposes the two steps of the lookup separately.
getSuperRegClassMaskOffsets() locates the offsets of a class, and
getSuperRegClassMaskAt() resolves one of them to a mask, so that
SuperRegClassIterator can locate the offsets once in its constructor and
have one load per step. getSuperRegClassMask() performs both steps and
serves callers that want a single mask. Walking the masks by striding no
longer works, and the iterator no longer needs the number of register
classes to compute the stride.
Compiling llvm/test/CodeGen/AMDGPU/amdgcn.bitcast.1024bit.ll, which
bitcasts between 1024-bit register classes and so calls
getCommonSuperRegClass heavily, is consistently slower, by an amount too
small to measure reliably and under half a percent. Compiling for other
targets, and starting llc up, show no difference.
Co-Authored-By: Claude
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Use the Module / Triple's correct long double type. Previously this
was hardcoded to assume double.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
These represent a halving subtract: trunc(shr(sub(ext(X), ext(Y)), 1)),
rounding towards negative infinity. They correspond to AArch64
shsub/uhsub and RISC-V P extension asub/asubu.
Includes some legalization, known bits, constant folding, and a
DAGCombiner fold from (sr[al] (sub nsw/nuw x, y), 1).
The operation is not legal any target yet. That will be done in follow
ups.
This is the same as #231749 with RISC-V split into a stack so we can
have 2 commits.
Co-Authored-By: Claude Sonnet 5.5
[noreply@anthropic.com](mailto:noreply@anthropic.com)
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
All these were taking a MachineFunction argument but just accessed the
internal Function
Followup to #229482 which added the getRecipEstimateSqrtEnabled Function
variant to simplify access via TTI for cost analysis
In the loop vectorizer we support early exit vectorization with side
effects by masking instructions after the first taken exit.
To do so it emits a mask that masks off every lane after the first exit
condition is met:
```llvm
%cttz = call i64 @llvm.experimental.cttz.elts(<vscale x 4 x i1> %exitcond, /*isZeroPoison*/ i1 false)
%mask = call <vscale x 4 x i1> @llvm.get.active.lane.mask(i64 0, i64 %cttz)
```
Which in turn is equivalent to
```llvm
%cttz = call i64 @llvm.experimental.cttz.elts(<vscale x 4 x i1> %exitcond, i1 false)
%cttz.head = insertelement <vscale x 4 x i64> poison, i64 %cttz, i32 0
%cttz.splat = shufflevector <vscale x 4 x i64> %cttz.head, <vscale x 4 x 64> poison, <vscale x 4 x i32> zeroinitializer
%stepvector = call <vscale x 4 x i64> @llvm.stepvector()
%mask = icmp ult <vscale x 4 x i64> %stepvector, %cttz.splat
```
AArch64 SVE and RISC-V RVV both have dedicated mask instructions for
this pattern, `brkb` and `vmsbf.m` respectively. I think X86 also has
something similar with `blsmsk`.
AArch64 currently generates `brkb` through a combine on
`get.active.lane.mask` added in #178674, but adding a similar combine
for RISC-V is trickier because it doesn't support `get.active.lane.mask`
natively and it gets instead expanded in SelectionDAGBuilder. The
expansion is also fairly complex to match because the sequence needs
`isZeroPoison=false`, and RISC-V's `cttz.elts` instruction `vfirst.m`
doesn't return the length of the vector when all elements are zero.
In addition to this, the `cttz.elts` + `get.active.lane.mask` sequence
is overly expensive in the cost model since it has to be treated as
materializing and comparing two i64 vectors on RISC-V.
Given the issues with trying to combine and cost model it, and also
given that this pattern maps well to instructions across several
targets, this PR proposes to add a dedicated intrinsic for it,
`@llvm.mask.beforefirst`:
```llvm
%mask = call <vscale x 4 x i1> @llvm.mask.beforefirst(<vscale x 4 x i1> %exitcond)
```
The semantics are as described above, and the intrinsic is restricted to
i1 vector types. This PR implements lowering for natively supported
vector types in SVE and RVV, as well as a basic generic expansion to the
equivalent `get.active.lane.mask` sequence in LegalizeVectorOps. Follow
up PRs would add more type legalization and improve codegen for fixed
length vectors on SVE + RISC-V, as well as teach the loop vectorizer to
emit it.
Add a getModule() helper method, which gets the module from the
insertion point. In the future, this will hopefully return the module
stored directly in IRBuilder.
The scalar sqrt, divided into with the reciprocal allowed, is folded
with
the division into the rsqrt* estimate sequence. Report no cost for it
when
the type has the estimate and the function does not disable it, so the
vectorizers do not pack it and break the folding.
Assisted-by: Cursor
Take the triple from the contextual module rather than TargetMachine
when it's already readily available.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
MachineBlockPlacement aligns the backedge destination after loop
rotation, which may not be the LoopInfo header. Query that block for the
32-byte request and the 4-byte pad cap so they stay consistent.
## Summary
- Pass the block being aligned into `getPrefLoopAlignment` so gfx950
fetch-window alignment uses the backedge destination, not only the
LoopInfo header.
- Unrotated 8-byte headers still get capped.
- Rotated 4-byte landing pads are no longer given uncapped 32-byte
alignment.
Remove the shim methods from the TargetMachine's copy of the DataLayout,
which will soon be eliminated. The Module owns the authoritative DataLayout,
so callers should read the value from the contextual Module.
Completely unreasonably, Mips's ABI name can change the pointer size which
we probably should just not support. Many other triple checks will never be
correct. This avoids potential mismatches in these contexts, but I still expect
this to be widely broken.
Some of the TargetLowering constructor changes and AMDGPULegalizerInfo
changes are kind of annoying. We could pass in the DataLayout through the
subtarget constructors but it didn't seem worth the effort and the information
should be derivable from the triple anyway.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply@anthropic.com>
This PR introduces `bitinsert` and `bitextract` instructions for LLVM
IR. These allow bit manipulation for byte types. Both were lowered to
GlobalIsel and SDag.
Tests were added for AArch64, AMDGPU, ARM, PowerPC, RISCV, x86 and LLVM
IR.
The LangRef was updated to document the new instructions.
The lowering of `bitextract` and `bitinsert` instructions are
implemented using integer operations.
In order to obtain the results for `bitextract`, a shift right
instruction with a specific offset is used (that can be a variable or an
immediate).
Relative to floating-point, in `bitinsert`, we reinterpret the bits of
the floating-point value as if it is an integer.
Pointer operands and results are reinterpreted as if by bitcast, as
specified in the LangRef.
This PR is based on the RFC:
https://discourse.llvm.org/t/rfc-bitinsert-and-bitextract-instructions-for-llvm-ir-2/90764
A step in the direction of removing the shouldExpandGetActiveLaneMask
TTI hook. For this PR I've implemented enough functionality to allow all
legalish fixed-length variants of get.active.lane.mask to bypass the
SelectionDAGBuilder based expansion for AArch64.
The AArch64TargetLowering::shouldExpandGetActiveLaneMask restrictions
are related to maintaining current code quality and not because the
expansion code cannot handle them.
Tests are a copy of active_lane_mask.ll with the scalable vector tests
removed.
The field's only effect was gating the __aeabi_mem*[4|8] libcalls via
the IsEABI4/IsEABI5 predicates. That distinction is derivable from the
triple's environment, so replace the two predicates with a single
triple-derived IsEABIVersion and delete the field.
The clang -meabi option and clang::TargetOptions::EABIVersion are
retained (now codegen-inert); the llc/opt -meabi flag is removed. -meabi
now only takes effect on triples with a bare-EABI/GNU environment pair
(arm-none-eabi <-> gnueabi), which is the only case with a triple
representation.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply@anthropic.com>
The two facts are about different pointers. `!dereferenceable` on a load
"tells the optimizer that the value loaded is known to be
dereferenceable" while `MachineMemOperand::MODereferenceable` says the
access itself doesn't trap.
Middle end passes need to be able to reason about library call
availability and potentially emit them without depending on codegen.
TargetLibraryInfo already lives in Analysis, and this is a step towards
the eventual merger. For now this is a mostly mechanical move, type
erasing the reference to TargetSubtargetInfo.
The per-subtarget customization (TargetSubtargetInfo::initLibcallLoweringInfo)
is inverted into a caller-supplied function_ref, so the Analysis types
carry no CodeGen/TargetSubtargetInfo reference. The module map is keyed on
an opaque erased pointer. CodeGen continues looking up based on the subtarget.
It is not yet in a state where it is usable from middle end passes; that
will come later. In principle we should be able to write arbitrary rules based
on a function's ABI attributes for which calls can be used.
Co-authored-by: Claude (Claude Opus 4.8) <noreply@anthropic.com>
Decompose fixed-length, non-power-of-two vectors into legal vector
parts, rather than scalarizing these. Apply this only to internal register
values.
Continue using the existing scalar breakdown for arguments and returns,
preserving the existing calling convention behaviour.
This is now fully replaced with the "float-abi" module flag.
If the module flag is not present, the default is computed
from the triple. Consumers are updated to read the module flag.
RuntimeLibraryAnalysis now defers analysis until run() on a Module,
instead of during the pass constructor as before. This requires copying
all of the remaining relevant TargetOptions so they are available
when the module is seen.
Unfortunately, ARM still depends on TargetOptions for determining
the float-abi. -target-abi=aapcs16 still changes the default float-abi,
but an explicit module flag wins.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply@anthropic.com>
Summary:
Currently we maintain several different spaces that want to ask which
libcall an intrinsic / type value lowers to. This PR consolidates this
into tablegen by emitting floating point families. Change
getLibcallForIntrinsic to take FunctionType and derive the FP type
from the complete call signature, rather than requiring callers to pass
a preselected type.
This resolves some outstanding TODOs. The main motivation is a follow-up
where we use this information to augment the LTO pass to more
intentionally extract symbols. I.e. if we see `llvm.sin.f64` we should
extract `sin` from an LTO library.
This adds a new `ISD::VECTOR_MATCH` opcode that corresponds to the
`experimental.vector.match` intrinsic and implements basic type
legalization.
Right now, this does not support many more cases than the existing
lowering. A follow up patch will handle supporting needle sizes <= the
maximum size without falling back to expansion on AArch64.
Assisted-by: Codex
Avoid defining synthetic LibcallImpls just to match the use
case of the legalizer. __aeabi_?cmpeq returns a boolean for
ordered-equal and was defined twice with __oeq/__une enum
suffixes so the one symbol could serve both OEQ and UNE.
Replace each pair with a single unsuffixed impl providing only
OEQ. The legalizer can directly invert it without the dummy entry.
Co-authored-by: Claude (Opus 4.8) <noreply@anthropic.com>
X86 has pseudo fmin/fmax operations that implement `x olt y ? x : y` and
`x ogt y ? x : y` respectively. There are other targets that also
support these operations, including wasm and s390x.
On wasm (where I've adopted the "pseudo" terminology from), we currently
create these ops, but incorrectly (wrt signed zero handling). On s390x
we don't, but should to avoid regressions from fixing incorrect
minnum/maxnum formation.
I figured it would make sense to uplift the existing support form X86,
so other targets can benefit from it by just marking the operations
legal.
The expansion converts a native IEEE float to an arbitrary-precision FP
format, returning the result as an integer, following this algorithm:
1. Bitcast the source float to an integer and extract sign, exponent,
and mantissa bit fields via masks and shifts.
2. Classify the input (zero/denormal/normal/Inf/NaN).
3. Normalize the source via FFREXP.
4. Normal path: adjust the exponent bias from source to destination
format and truncate the mantissa with rounding (supports
NearestTiesToEven, TowardZero, TowardPositive, TowardNegative,
NearestTiesToAway).
5. Denormal destination path: when the biased destination exponent is <=
0, shift the mantissa right to produce a denormalized result with
rounding.
6. Handle mantissa overflow from rounding and exponent overflow. Produce
Inf or saturate to max finite, depending on format and saturation flag.
7. Build special-value results (canonical qNaN, signed Inf, signed zero)
adapted to the destination format's non-finite behavior (IEEE754,
NanOnly, FiniteOnly).
8. Final selection in priority order: NaN > Inf > Zero > Overflow >
Normal/Denorm.
Currently only conversions to OCP floats are covered, in LLVM terms
these are: Float8E5M2, Float8E4M3FN, Float6E3M2FN, Float6E2M3FN,
Float4E2M1FN.
OCP spec:
https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf
E2E testing on X86 done with an assistance of Claude Code Opus 4.6.
SelectionDAGBuilder previously dropped the is_int_min_poison flag on
llvm.abs, lowering both variants to ISD::ABS. This is unsound for
certain targets like NVPTX whose native abs.s is poison on INT_MIN. This
PR adds a new ISD::ABS_MIN_POISON opcode, emits it for llvm.abs(x, true)
and threads through legalization, SDAG folding. The default action for
this is Expand with a fallback to the original ISD::ABS. DAGCombiner
adds visitABS_MIN_POISON which mirrors visitABS and two new folds:
abs_min_poison(freeze(abs x)) -> freeze(abs x) and
abs_min_poison(sign_extend_inreg x) → zext(abs(trunc x)). PromoteIntRes,
ExpandIntRes, and widenAbs now emit ABS_MIN_POISON whenever the input
provably can't be the wide INT_MIN. NVPTX fix to match abs.s against
abs_min_poison and tests updated accordingly.
DAG/GISel are ambiguous about whether zero-input results in
UNDEF/POISON, unlike the rest of LLVM which makes it clear its POISON.
I've tried to clean this up once and for all by ensuring
SelectionDAG::canCreateUndefOrPoison does a includesPoison(Kind) check,
renaming the opcodes (including the VP variants) and updating as many
comments/tests as possible (I may still have missed some...).
IRTranslator::translateLoad is hot and showing up in compile-time
profiling of sqlite on aarch64-O0-g builds. Around 1/3 of the time is
spent in TargetLoweringBase::getLoadMemOperandFlags which is dominated
by isDereferenceableAndAlignedPointer inferring dereferenceable
metadata.
This metadata is for the optimizer and not necessary for correctness.
Skipping at O0 is -0.21% geomean improvement on CTMark. This brings
GISel more inline with FastISel which also doesn't infer this metadata.
https://llvm-compile-time-tracker.com/compare.php?from=4e6d3722fca73c97367720180a8d547057fda380&to=93a4a4a09ee9c94ef39bf07ee859cbb7c199c94e&stat=instructions%3Au
- Adds amd_vrd2_sincos to RuntimeLibcalls.td.
- Adds v8f32, v16f32, v4f64, and v8f64 cases to getSINCOS().
- Enables the AMDLIBM sincos in RuntimeLibcallsInfo.
This change does a couple of related things:
1) It changes the default expansion strategy for scalable
vectors for fcanonicalize. This switches us from
emitting a loop (directly parallel to unrolling)
to using the already available fmul expansion.
2) Mark RISC-V legal scalable vector types as Expand
to leverage the previous item.
3) Wrap fixed vector types in their corresponding
scalable types to avoid unrolling.
The net effect is to improve the lowering for fixed vector cases and to
no longer crash for the scalable ones. We were crashing because the
scalable cases were marked Legal, not Expand. We could have just fixed that, but doing everyone at once seemed like a good investment.
Note that we can also choose to follow Aarch64 and consider a vfmin
based lowering. I left that until later thought it is worthwhile noting
that's what we do for scalar code.
This reverts commit a1d11348ab.
Two problems have been identified:
- The expansion for powi was functionally wrong - the second argument
stales scalar even when the first is a vector.
- AArch64 uses the Expand option on libcalls to select vector libcalls
in some cases. The test coverage for this uses -start-after which
happens to miss this pass.
This expands the set of scalable typed binary intrinsics which can be
expanded to match the entire set of builtin element wise routines
provided by clang. Support for the binary ones will follow in a separate
patch.
Note that the lowering quality is terrible, particularly when the libc
entry for the scalar routine doesn't preserve vector registers (e.g.
RISC-V default). This is a functional fix to avoid crashes when trying
to codegen these, nothing more.
Written by Claude, sanity checked by me.
This expands the set of scalable typed unary intrinsics which can be
expanded to match the entire set of builtin element wise routines
provided by clang. Support for the binary ones will follow in a separate
patch.
Note that the lowering quality is terrible, particularly when the libc
entry for the scalar routine doesn't preserve vector registers (e.g.
RISC-V default). This is a functional fix to avoid crashes when trying
to codegen these, nothing more.
Written by Claude, sanity checked by me.
This trivial method makes more sense in the header (indeed, both the
existing overrides for it are already in headers).
I noticed this while hunting for the default value while reviewing
#192425
Because division by zero is undefined behaviour, when the loop
vectorizer encounters a div that's not unconditionally executed it needs
to replace its divisor with a non-zero value on any lane that wouldn't
have been executed in the scalar loop:
%safedivisor = select <vscale x 2 x i1> %mask, <vscale x 2 x i64> %divisor, <vscale x 2 x i64> splat (i64 1)
%res = udiv <vscale x 2 x i64> %dividend, %safedivisor
https://godbolt.org/z/jczc3ovbr
We need this for architectures like x86 where division by zero (or
overflow for sdiv/srem) can trap. But on AArch64 and RISC-V division
doesn't trap so we don't actually need to mask off any divisors. Not
only that, but there are also dedicated vector division instructions
that can be predicated.
Originally we tried to optimize this on RISC-V by transforming `udiv x,
(select mask, y, 1) -> vp.udiv x, y, mask`. However this isn't actually
a correct transform because the masked off lanes aren't poison, but x.
So with the safe-divisor pattern we end up losing the information that
the masked off lanes aren't actually used and can be poison.
This patch adds masked intrinsics for udiv and friends to
represent the semantics where the masked off lanes don't trap and
produce poison. This will allow AArch64 and RISC-V to emit their native
predicated division instructions and avoid the redundant select
instruction.
%res = call <vscale x 4 x i32> @llvm.masked.udiv(<vscale x 4 x i32> %x, <vscale x 4 x i32> %y, <vscale x 4 x i1> %m)
This is a second attempt at "[SelectionDAG] Expand
CTTZ_ELTS[_ZERO_POISON] and handle splitting" (#188220)
That PR had to be reverted in 7d39664a6a
because we had crashes on AMDGPU since we didn't have scalarization
support, and other crashes on PowerPC because we didn't handle the case
when a vector needed widened. Tests for these are added in
AMDGPU/cttz-elts.ll, RISCV/rvv/cttz-elts-scalarize.ll and
PowerPC/cttz-elts.ll.
The former crash has been fixed by adding
DAGTypeLegalizer::ScalarizeVecOp_CTTZ_ELTS.
The second crash has been fixed by reworking
TargetLowering::expandCttzElts. The expansion for CTTZ_ELTS is nearly
identical to VECTOR_FIND_LAST_ACTIVE, except it uses a reverse step
vector and subtracts the result from VF. The easiest way to fix these
crashes without introducing regressions is to reuse the
VECTOR_FIND_LAST_ACTIVE expansion which already handles the case where
the vector needs widened.
This means that the node now needs to take in a boolean vector argument
and uses VSELECT instead of an AND to zero out inactive lanes, so the op
promotion code has also been shared.
Currently a cttz.elts of e.g. nxv32i1 will get expanded to a reduction
of nxv32i64 or equivalent, but we can split it into two legal nxv16i1
cttz.elts once we have dedicated SelectionDAG nodes.
This implements the splitting for them the same way we implement type
splitting for vp.cttz.elts, i.e. check if the low result is VF, and if
so add it to the result of the high result. It also implements operand
type promotion for NEON which needs to promote i1 vectors to something
larger first.
We also need to move expansion into LegalizeVectorOps so it doesn't get
expanded before type legalization can do splitting. This uses
LegalizeVectorOps in case the scalar reduction type, which depends on
the minimum bitwidth needed to store the result, still needs type
promotion.
The TTI costs should be updated after this to reflect the more efficient
codegen, but that is deferred to another PR.
Currently llvm.experimental.cttz.elts are directly lowered from the
intrinsic.
If the type isn't legal then the target tells SelectionDAGBuilder to
expand it into a reduction, but this means we can't split the operation.
E.g. it's possible to split a cttz.elts nxv32i1 into two nxv16i1,
instead of expanding it into a nxv32i64 reduction.
vp.cttz.elts can be split because it has a dedicated SelectionDAG node.
This adds CTTZ_ELTS and CTTZ_ELTS[_ZERO_POISON] nodes and just enough
legalization to get tests passing. A follow up patch will add splitting
and move the expansion into LegalizeDAG.
BranchInst currently represents both unconditional and conditional
branches. However, these are quite different operations that are often
handled separately. Therefore, split them into separate opcodes and
classes to allow distinguishing these operations in the type system.
Additionally, this also slightly improves compile-time performance.
The expansion converts arbitrary-precision FP represented as integer
following these algorithm:
1. Extract sign, exponent, and mantissa bit fields via masks and shifts.
2. Classify the input (zero, denormal, normal, Inf, NaN) using the
exponent and mantissa fields.
3. Normal path: adjusting the exponent bias and left-shifting the
mantissa to fit the wider destination format.
4. Denormal path: normalizing by finding the MSB position of the
mantissa (via count-leading-zeros), computing the correct exponent from
that position, stripping the implicit leading 1, and shifting the
fraction into the destination mantissa field.
5. Assemble the destination IEEE bit pattern (sign | exponent |
mantissa) and select among the normal, denormal, and special-value
results.
Currently only conversions from OCP floats are covered, in LLVM terms
these are: Float8E5M2, Float8E4M3FN, Float6E3M2FN, Float6E2M3FN,
Float4E2M1FN.
OCP spec:
https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf
AI has assisted in X86 E2E testing.
This patch teaches the backend how to lower the FCBRT DAG node to the
vector math library function when using ArmPL. This is similar to what
we already do for llvm.pow/FPOW, however the only way to expose this is
via a DAG combine that converts
FPOW(<2 x double> %x, <2 x double> <double 1.0/3.0, double 1.0/3.0>)
into
FCBRT(<2 x double> %x)
when the appropriate fast math flags are present on the node. I've
updated the DAG combine to handle vector types and only perform the
transformation if there exists a vector library variant of cbrt.
This patch is split off from PR #183319 and teaches the backend how to
lower the FPOW DAG node to the vector math library function when using
ArmPL. This is similar to what we already do for llvm.sincos/FSINCOS
today.
Instead of directly checking if the target is android, check if
__safestack_pointer_address is available and configure android
to have the call. Maintain the -safestack-use-pointer-address cl::opt
in an unclean way by ignoring libcall availability.
Also add a RuntimeLibcallsInfo entry for __safestack_unsafe_stack_ptr,
similar to other special globals. Also add this unconditionally to most targets,
even though this seems contrary to reality. A few tests rely on unsupported OSes, so
leave that alone for now.
