[SDAG] avoid generating libcall to function with same name

This is a potentially better alternative to D131452 that also
should avoid the infinite loop bug from:
issue #56403

This is again a minima

[SDAG] avoid generating libcall to function with same name

This is a potentially better alternative to D131452 that also
should avoid the infinite loop bug from:
issue #56403

This is again a minimal fix to reduce merging pain for the
release. But if this makes sense, then we might want to guard
all of the RTLIB generation (and other libcalls?) with a
similar name check.

Differential Revision: https://reviews.llvm.org/D131521

(cherry picked from commit 7f72a0f5bb3743428021df920d9a7c50f74f61ae)

show more ...

[DAG] ExpandIntRes_ADDSUB - create UADDO/USUBO instead of ADDCARRY/SUBCARRY if overflow is known to be zero

As noticed on D127115, when splitting ADD/SUB nodes we often end up with cases where overf

[DAG] ExpandIntRes_ADDSUB - create UADDO/USUBO instead of ADDCARRY/SUBCARRY if overflow is known to be zero

As noticed on D127115, when splitting ADD/SUB nodes we often end up with cases where overflow from the lower bits is impossible - in such cases we're better off breaking the carry chain dependency as soon as possible.

This path is being exercised by llvm/test/CodeGen/ARM/dsp-mlal.ll, although I haven't been able to get any codegen diff without a topological worklist.

show more ...

[DAG] PromoteIntRes_BUILD_VECTOR - extend constant boolean vectors according to target BooleanContents

PromoteIntRes_BUILD_VECTOR currently always ANY_EXTENDs build vector operands, but if this is a

[DAG] PromoteIntRes_BUILD_VECTOR - extend constant boolean vectors according to target BooleanContents

PromoteIntRes_BUILD_VECTOR currently always ANY_EXTENDs build vector operands, but if this is a constant boolean vector we're losing the useful ability to keep the vector matching the BooleanContents mode used by the target.

This patch extends constant boolean vectors according to target BooleanContents, allowing a number of additional all-bits folds (notable XOR -> NOT conversions) to occur.

Differential Revision: https://reviews.llvm.org/D129641

show more ...

[VP] Legalize the stride operand for EXPERIMENTAL_VP_STRIDED SDNodes

Add promotion and expansion of integer operands for
experimental_vp_strided SelectionDAG nodes; the expansion is actually
just a

[VP] Legalize the stride operand for EXPERIMENTAL_VP_STRIDED SDNodes

Add promotion and expansion of integer operands for
experimental_vp_strided SelectionDAG nodes; the expansion is actually
just a truncation of the stride operand.

Reviewed By: simoll

Differential Revision: https://reviews.llvm.org/D123112

show more ...

[stackmaps] Legalise patchpoint arguments.

This is similar to D125680, but for llvm.experimental.patchpoint
(instead of llvm.experimental.stackmap).

Differential review: https://reviews.llvm.org/D1

[stackmaps] Legalise patchpoint arguments.

This is similar to D125680, but for llvm.experimental.patchpoint
(instead of llvm.experimental.stackmap).

Differential review: https://reviews.llvm.org/D129268

show more ...

[LegalizeTypes] Replace vecreduce_xor/or/and with vecreduce_add/umax/umin if not legal

This is done during type legalization since the target representation of
these nodes may not be valid until aft

[LegalizeTypes] Replace vecreduce_xor/or/and with vecreduce_add/umax/umin if not legal

This is done during type legalization since the target representation of
these nodes may not be valid until after type legalization, and after
type legalization the fact that these are dealing with i1 types may be
lost.

Differential Revision: https://reviews.llvm.org/D128996

show more ...

[stackmaps] Start legalizing live variable operands

Prior to this change, live variable operands passed to
`llvm.experimental.stackmap` would be emitted directly to target nodes,
meaning that they d

[stackmaps] Start legalizing live variable operands

Prior to this change, live variable operands passed to
`llvm.experimental.stackmap` would be emitted directly to target nodes,
meaning that they don't get legalised. The upshot of this is that LLVM
may crash when encountering illegally typed target nodes.

e.g. https://github.com/llvm/llvm-project/issues/21657

This change introduces a platform independent stackmap DAG node whose
operands are legalised as per usual, thus avoiding aforementioned
crashes.

Note that some kinds of argument are still not handled properly, namely
vectors, structs, and large integers, like i128s. These will need to be
addressed in follow-up changes.

Note also that this does not change the behaviour of
`llvm.experimental.patchpoint`. A follow up change will do the same for
this intrinsic.

Differential review:
https://reviews.llvm.org/D125680

show more ...

[LegalizeTypes][NFC] Merge promote SPLAT_VECTOR and promote SCALAR_TO_VECTOR to one function

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D127825

[LegalizeTypes][RISCV][NFC] Modify assert in PromoteIntRes_STEP_VECTOR and add some tests for RISCV

Reviewed By: david-arm

Differential Revision: https://reviews.llvm.org/D127939

[SelectionDAG] Remove invalid TypeSize conversion from PromoteIntRes_BITCAST.

Extend the TypeWidenVector case of PromoteIntRes_BITCAST to work
with TypeSize directly rather than silently casting to

[SelectionDAG] Remove invalid TypeSize conversion from PromoteIntRes_BITCAST.

Extend the TypeWidenVector case of PromoteIntRes_BITCAST to work
with TypeSize directly rather than silently casting to unsigned.

To accomplish this I've extended TypeSize with an interface that
essentially allows TypeSize division when both operands have the
same number of dimensions.

There still exists combinations of scalable vector bitcasts that
cause compiler crashes. I call these out by adding "is missing"
entries to sve-bitcast.

Depends on D126957.
Fixes: #55114

Differential Revision: https://reviews.llvm.org/D127126

show more ...

[LegalizeTypes][VP] Add integer promotion support for vp.fptosi/vp.fptoui

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D125760

[SelectionDAG][NFC] Simplify integer promotion in setcc/vp.setcc

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D126516

[LegalizeTypes][VP] Add integer promotion support for vp.sitofp/vp.uitofp

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D125960

[APInt] Remove all uses of zextOrSelf, sextOrSelf and truncOrSelf

Most clients only used these methods because they wanted to be able to
extend or truncate to the same bit width (which is a no-op).

[APInt] Remove all uses of zextOrSelf, sextOrSelf and truncOrSelf

Most clients only used these methods because they wanted to be able to
extend or truncate to the same bit width (which is a no-op). Now that
the standard zext, sext and trunc allow this, there is no reason to use
the OrSelf versions.

The OrSelf versions additionally have the strange behaviour of allowing
extending to a *smaller* width, or truncating to a *larger* width, which
are also treated as no-ops. A small amount of client code relied on this
(ConstantRange::castOp and MicrosoftCXXNameMangler::mangleNumber) and
needed rewriting.

Differential Revision: https://reviews.llvm.org/D125557

show more ...

[LegalizeTypes][VP] Add integer promotions support for VP_TRUNCATE

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D125739

[LegalizeTypes][VP][NFC] Use an if and two returns instead of ?: operator

Reviewed By: frasercrmck

Differential Revision: https://reviews.llvm.org/D125858

[LegalizeTypes][VP] Add integer promotion support for vp.setcc

Reviewed By: frasercrmck

Differential Revision: https://reviews.llvm.org/D125453

[LegalizeTypes][VP] Add integer promotion support for vp.merge

Reviewed By: frasercrmck

Differential Revision: https://reviews.llvm.org/D125452

[LegalizeTypes] Make use of SelectionDAG::getShiftAmountConstant. NFC

Instead of calling getShiftAmountTy and getConstant separately.

[LegalizeTypes] Don't assume fshl/fshr shift amount type matches the other operands.

Like other shifts, the type isn't required to match. We shouldn't
assume we can call ZExtPromotedInteger.

I test

[LegalizeTypes] Don't assume fshl/fshr shift amount type matches the other operands.

Like other shifts, the type isn't required to match. We shouldn't
assume we can call ZExtPromotedInteger.

I tested the PromoteIntOp_FunnelShift locally by removing the promotion
of the shift amount from PromoteIntRes_FunnelShift. But with the final
version of this patch it is never executed on any tests.

Differential Revision: https://reviews.llvm.org/D125106

show more ...

[SelectionDAG] Clear promoted bits before UREM on shift amount in PromoteIntRes_FunnelShift.

Otherwise we have garbage in the upper bits that can affect the
results of the UREM.

Fixes PR55296.

Dif

[SelectionDAG] Clear promoted bits before UREM on shift amount in PromoteIntRes_FunnelShift.

Otherwise we have garbage in the upper bits that can affect the
results of the UREM.

Fixes PR55296.

Differential Revision: https://reviews.llvm.org/D125076

show more ...

Intrinsic for checking floating point class

This change introduces a new intrinsic, `llvm.is.fpclass`, which checks
if the provided floating-point number belongs to any of the the specified
value cl

Intrinsic for checking floating point class

This change introduces a new intrinsic, `llvm.is.fpclass`, which checks
if the provided floating-point number belongs to any of the the specified
value classes. The intrinsic implements the checks made by C standard
library functions `isnan`, `isinf`, `isfinite`, `isnormal`, `issubnormal`,
`issignaling` and corresponding IEEE-754 operations.

The primary motivation for this intrinsic is the support of strict FP
mode. In this mode using compare instructions or other FP operations is
not possible, because if the value is a signaling NaN, floating-point
exception `Invalid` is raised, but the aforementioned functions must
never raise exceptions.

Currently there are two solutions for this problem, both are
implemented partially. One of them is using integer operations to
implement the check. It was implemented in https://reviews.llvm.org/D95948
for `isnan`. It solves the problem of exceptions, but offers one
solution for all targets, although some can do the check in more
efficient way.

The other, implemented in https://reviews.llvm.org/D96568, introduced a
hook 'clang::TargetCodeGenInfo::testFPKind', which injects a target
specific code into IR to implement `isnan` and some other functions. It is
convenient for targets that have dedicated instruction to determine FP data
class. However using target-specific intrinsic complicates analysis and can
prevent some optimizations.

A special intrinsic for value class checks allows representing data class
tests with enough flexibility. During IR transformations it represents the
check in target-independent way and saves it from undesired transformations.
In the instruction selector it allows efficient lowering depending on the
used target and mode.

This implementation is an extended variant of `llvm.isnan` introduced
in https://reviews.llvm.org/D104854. It is limited to minimal intrinsic
support. Target-specific treatment will be implemented in separate
patches.

Differential Revision: https://reviews.llvm.org/D112025

show more ...

[NFC] Remove redundant IndexType canonicalisation from DAGTypeLegalizer::PromoteIntOp_MSCATTER

Promotion does not affect the base element type and so the original
index type will remain unchanged.

[NFC] Remove redundant IndexType canonicalisation from DAGTypeLegalizer::PromoteIntOp_MSCATTER

Promotion does not affect the base element type and so the original
index type will remain unchanged. This reflects the behaviour of
DAGTypeLegalizer::PromoteIntOp_MGATHER with no tests affected.

show more ...

[SelectionDAG] Emit calls to __divei4 and friends for division/remainder of large integers

Emit calls to __divei4 and friends for divison/remainder of large integers.

This fixes https://github.com/

[SelectionDAG] Emit calls to __divei4 and friends for division/remainder of large integers

Emit calls to __divei4 and friends for divison/remainder of large integers.

This fixes https://github.com/llvm/llvm-project/issues/44994.

The overall RFC is in https://discourse.llvm.org/t/rfc-add-support-for-division-of-large-bitint-builtins-selectiondag-globalisel-clang/60329

The compiler-rt part is in https://reviews.llvm.org/D120327

Differential Revision: https://reviews.llvm.org/D120329

show more ...

[LegalizeTypes][RISCV][WebAssembly] Expand ABS in PromoteIntRes_ABS if it will expand to sra+xor+sub later.

If we promote the ABS and then Expand in LegalizeDAG, then both the
sra and the xor will h

[LegalizeTypes][RISCV][WebAssembly] Expand ABS in PromoteIntRes_ABS if it will expand to sra+xor+sub later.

If we promote the ABS and then Expand in LegalizeDAG, then both the
sra and the xor will have their inputs sign extended. This generates
extra code on RISCV which lacks an i8 or i16 sign extend instructon.
If we expand during type legalization, then only the sra will get its
input sign extended. RISCV is able to combine this with the sra by
doing a shift left followed by an sra.

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D121664

show more ...