[DAG] Add optional AllowUndefs to isNullOrNullSplat

No change in default behaviour (AllowUndefs = false)

llvm-svn: 353646

[SDAG] Add SDNode/SDValue getConstantOperandAPInt helper. NFCI.

We already have the getConstantOperandVal helper which returns a uint64_t, but along comes the fuzzer and inserts a i128 -1 constant o

[SDAG] Add SDNode/SDValue getConstantOperandAPInt helper. NFCI.

We already have the getConstantOperandVal helper which returns a uint64_t, but along comes the fuzzer and inserts a i128 -1 constant or something and the whole thing asserts.......

I've updated a few obvious cases, and tried to make use of the const reference where possible, but there's more to do. A number of existing oss-fuzz tickets should be fixed if we start using APInt and perform value clamping where necessary.

llvm-svn: 352961

show more ...

Codegen support for atomicrmw fadd/fsub

llvm-svn: 351851

Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>

As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectat

Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>

As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.

This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.

Note that the following specialization were invalid:

std::pair<T0, T1>
llvm::Optional<T>

Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.

As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)

Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.

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

llvm-svn: 351701

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[SelectionDAG] Add static getMaxNumOperands function to SDNode.

Summary:
Use this helper to make sure we use the same value at various places.
This will likely be needed at more places were we curre

[SelectionDAG] Add static getMaxNumOperands function to SDNode.

Summary:
Use this helper to make sure we use the same value at various places.
This will likely be needed at more places were we currently crash
because we use more operands than possible.

Also makes it easier to change in the future.

Reviewers: RKSimon, craig.topper, efriedma, aemerson

Reviewed By: RKSimon

Subscribers: hiraditya, arsenm, llvm-commits

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

llvm-svn: 351537

show more ...

[SelectionDAG] Optional handling of UNDEF elements in matchBinaryPredicate (part 1 of 2)

Now that SimplifyDemandedBits/SimplifyDemandedVectorElts is simplifying vector elements, we're seeing more co

[SelectionDAG] Optional handling of UNDEF elements in matchBinaryPredicate (part 1 of 2)

Now that SimplifyDemandedBits/SimplifyDemandedVectorElts is simplifying vector elements, we're seeing more constant BUILD_VECTOR containing undefs.

This patch provides opt-in support for UNDEF elements in matchBinaryPredicate, passing NULL instead of the result ConstantSDNode* argument.

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

llvm-svn: 349628

show more ...

[SelectionDAG] Optional handling of UNDEF elements in matchUnaryPredicate

Now that SimplifyDemandedBits/SimplifyDemandedVectorElts are simplifying vector elements, we're seeing more constant BUILD_V

[SelectionDAG] Optional handling of UNDEF elements in matchUnaryPredicate

Now that SimplifyDemandedBits/SimplifyDemandedVectorElts are simplifying vector elements, we're seeing more constant BUILD_VECTOR containing UNDEFs.

This patch provides opt-in handling of UNDEF elements in matchUnaryPredicate, passing NULL instead of the ConstantSDNode* argument.

I've updated SelectionDAG::simplifyShift to demonstrate its use.

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

llvm-svn: 349616

show more ...

[SelectionDAG] move constant or splat functions to common location

rL347502 moved the null sibling, so we should group all of these
together. I'm not sure why these aren't methods of the SDValue
cla

[SelectionDAG] move constant or splat functions to common location

rL347502 moved the null sibling, so we should group all of these
together. I'm not sure why these aren't methods of the SDValue
class itself, but that's another patch if that's possible.

llvm-svn: 347523

show more ...

[DAG] consolidate shift simplifications

...and use them to avoid creating obviously undef values as
discussed in the post-commit thread for r347478.

The diffs in vector div/rem show that we were mi

[DAG] consolidate shift simplifications

...and use them to avoid creating obviously undef values as
discussed in the post-commit thread for r347478.

The diffs in vector div/rem show that we were missing real
optimizations by creating bogus shift nodes.

llvm-svn: 347502

show more ...

[FPEnv] Add constrained CEIL/FLOOR/ROUND/TRUNC intrinsics

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

llvm-svn: 346141

[FPEnv] [FPEnv] Add constrained intrinsics for MAXNUM and MINNUM

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

llvm-svn: 345650

[SelectionDAG] allow undefs when matching splat constants

And use that to transform fsub with zero constant operands.
The integer part isn't used yet, but it is proposed for use in
D44548, so adding

[SelectionDAG] allow undefs when matching splat constants

And use that to transform fsub with zero constant operands.
The integer part isn't used yet, but it is proposed for use in
D44548, so adding both enhancements here makes that
patch simpler.

llvm-svn: 343865

show more ...

[SelectionDAG] replace duplicated peekThroughBitcast helper functions; NFCI

x86 had 2 versions of peekThroughBitcast. DAGCombiner had 1. Plus, it had a 1-off implementation for the one-use variant.

[SelectionDAG] replace duplicated peekThroughBitcast helper functions; NFCI

x86 had 2 versions of peekThroughBitcast. DAGCombiner had 1. Plus, it had a 1-off implementation for the one-use variant.
Move the x86 versions of the code to SelectionDAG, so we don't have different copies of the code.
No functional change intended.

I'm putting this next to isBitwiseNot() because I am planning to use it in there. Another option is next to the
helpers in the ISD namespace (eg, ISD::isConstantSplatVector()). But if there's no good reason for those to be
there, I'd prefer to pull other helpers over to SelectionDAG in follow-up steps.

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

llvm-svn: 342669

show more ...

[SelectionDAG] add helper query for binops; NFC

We will also use this in a planned enhancement for vector insertelement.

llvm-svn: 340741

[SelectionDAG][X86] Reorder the operands the MaskedStoreSDNode to put the value first.

Summary:
Previously the value being stored is the last operand in SDNode. This causes the type legalizer to vis

[SelectionDAG][X86] Reorder the operands the MaskedStoreSDNode to put the value first.

Summary:
Previously the value being stored is the last operand in SDNode. This causes the type legalizer to visit the mask operand before the value operand. The type legalizer was more complicated because of this since we want the type of the value to drive the decisions.

This patch moves the value to be the first operand so we visit it first during type legalization. It also simplifies the type legalization code accordingly.

X86 is currently the only in tree target that uses this SDNode. Not sure if there are any users out of tree.

Reviewers: RKSimon, delena, hfinkel, eli.friedman

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 340689

show more ...

[SDAG] Remove the reliance on MI's allocation strategy for
`MachineMemOperand` pointers attached to `MachineSDNodes` and instead
have the `SelectionDAG` fully manage the memory for this array.

Prior

[SDAG] Remove the reliance on MI's allocation strategy for
`MachineMemOperand` pointers attached to `MachineSDNodes` and instead
have the `SelectionDAG` fully manage the memory for this array.

Prior to this change, the memory management was deeply confusing here --
The way the MI was built relied on the `SelectionDAG` allocating memory
for these arrays of pointers using the `MachineFunction`'s allocator so
that the raw pointer to the array could be blindly copied into an
eventual `MachineInstr`. This creates a hard coupling between how
`MachineInstr`s allocate their array of `MachineMemOperand` pointers and
how the `MachineSDNode` does.

This change is motivated in large part by a change I am making to how
`MachineFunction` allocates these pointers, but it seems like a layering
improvement as well.

This would run the risk of increasing allocations overall, but I've
implemented an optimization that should avoid that by storing a single
`MachineMemOperand` pointer directly instead of allocating anything.
This is expected to be a net win because the vast majority of uses of
these only need a single pointer.

As a side-effect, this makes the API for updating a `MachineSDNode` and
a `MachineInstr` reasonably different which seems nice to avoid
unexpected coupling of these two layers. We can map between them, but we
shouldn't be *surprised* at where that occurs. =]

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

llvm-svn: 339740

show more ...

[SelectionDAG][X86] Rename MaskedLoadSDNode::getSrc0 to getPassThru.

Src0 doesn't really convey any meaning to what the operand is. Passthru matches what's used in the documentation for the intrinsi

[SelectionDAG][X86] Rename MaskedLoadSDNode::getSrc0 to getPassThru.

Src0 doesn't really convey any meaning to what the operand is. Passthru matches what's used in the documentation for the intrinsic this comes from.

llvm-svn: 339101

show more ...

[SelectionDAG][X86] Rename getValue to getPassThru for gather SDNodes.

getValue is more meaningful name for scatter than it is for gather. Split them and use getPassThru for gather.

llvm-svn: 339096

[CodeGen] Fix inconsistent declaration parameter name

llvm-svn: 337200

[SelectionDAG] Remove debug locations from ConstantSD(FP)Nodes

This removes debug locations from ConstantSDNode and ConstantSDFPNode.

When this kind of node is materialized we no longer create a li

[SelectionDAG] Remove debug locations from ConstantSD(FP)Nodes

This removes debug locations from ConstantSDNode and ConstantSDFPNode.

When this kind of node is materialized we no longer create a line table
entry which jumps back to the constant's first point of use. This makes
single-stepping behavior smoother, and it matches the model used by IR,
where Constants have no locations. See this thread for more context:

http://lists.llvm.org/pipermail/llvm-dev/2018-June/124164.html

I'd like to handle constant BuildVectorSDNodes and to try to eliminate
passing SDLocs to SelectionDAG::getConstant*() in follow-up commits.

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

llvm-svn: 335497

show more ...

[DAG] add convenience function to propagate FMF; NFC

There's only one use of this currently, but that could
change with D46563. Either way, we shouldn't have to
update code outside of the flags stru

[DAG] add convenience function to propagate FMF; NFC

There's only one use of this currently, but that could
change with D46563. Either way, we shouldn't have to
update code outside of the flags struct when those
flag definitions change.

llvm-svn: 332155

show more ...

Fast Math Flag mapping into SDNode

Summary: Adding support for Fast flags in the SDNode to leverage fast math sub flag usage.

Reviewers: spatel, arsenm, jbhateja, hfinkel, escha, qcolombet, echrist

Fast Math Flag mapping into SDNode

Summary: Adding support for Fast flags in the SDNode to leverage fast math sub flag usage.

Reviewers: spatel, arsenm, jbhateja, hfinkel, escha, qcolombet, echristo, wristow, javed.absar

Reviewed By: spatel

Subscribers: llvm-commits, rampitec, nhaehnle, tstellar, FarhanaAleen, nemanjai, javed.absar, jbhateja, hfinkel, wdng

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

llvm-svn: 331547

show more ...

Remove \brief commands from doxygen comments.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they ar

Remove \brief commands from doxygen comments.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

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

llvm-svn: 331272

show more ...

Fix typo in static_assert for size of LoadSDNodeBitfields.

Reviewers: fhahn, jlebar, delena, RKSimon

Reviewed By: fhahn, jlebar

Subscribers: llvm-commits

Differential Revision: https://reviews.ll

Fix typo in static_assert for size of LoadSDNodeBitfields.

Reviewers: fhahn, jlebar, delena, RKSimon

Reviewed By: fhahn, jlebar

Subscribers: llvm-commits

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

llvm-svn: 330830

show more ...