Revert r237046. See the testcase on the thread where r237046 was committed.

llvm-svn: 237317

[DebugInfo] Debug locations for constant SD nodes

Several updates for [DebugInfo] Add debug locations to constant SD nodes (r235989).
Includes:

* re-enabling the change (disabled recently);
* m

[DebugInfo] Debug locations for constant SD nodes

Several updates for [DebugInfo] Add debug locations to constant SD nodes (r235989).
Includes:

* re-enabling the change (disabled recently);
* missing change for FP constants;
* resetting debug location of constant node if it's used more than at one place
to prevent emission of wrong locations in case of coalesced constants;
* a couple of additional tests.

Now all look ups in CSEMap are wrapped by additional method.

Comment in D9084 suggests that debug locations aren't useful for "target constants",
so there might be one more change related to this API (namely, dropping debug
locations for getTarget*Constant methods).

Differential Revision: http://reviews.llvm.org/D9604

llvm-svn: 237237

show more ...

fix typos, grammar; NFC

llvm-svn: 237139

propagate IR-level fast-math-flags to DAG nodes; 2nd try; NFC

This is a less ambitious version of:
http://reviews.llvm.org/rL236546

because that was reverted in:
http://reviews.llvm.org/rL236600

b

propagate IR-level fast-math-flags to DAG nodes; 2nd try; NFC

This is a less ambitious version of:
http://reviews.llvm.org/rL236546

because that was reverted in:
http://reviews.llvm.org/rL236600

because it caused memory corruption that wasn't related to FMF
but was actually due to making nodes with 2 operands derive from a
plain SDNode rather than a BinarySDNode.

This patch adds the minimum plumbing necessary to use IR-level
fast-math-flags (FMF) in the backend without actually using
them for anything yet. This is a follow-on to:
http://reviews.llvm.org/rL235997

...which split the existing nsw / nuw / exact flags and FMF
into their own struct.


llvm-svn: 237046

show more ...

Disable r235989 "Reapply r235977 "[DebugInfo] Add debug locations to constant SD nodes""

Will be re-enabled with missing changes for ConstantFPSDNode and
fixes for wrong locations due to constant co

Disable r235989 "Reapply r235977 "[DebugInfo] Add debug locations to constant SD nodes""

Will be re-enabled with missing changes for ConstantFPSDNode and
fixes for wrong locations due to constant coalescing.

llvm-svn: 236758

show more ...

Reformat.

llvm-svn: 236601

Revert r236546, "propagate IR-level fast-math-flags to DAG nodes (NFC)"

It caused undefined behavior.

llvm-svn: 236600

propagate IR-level fast-math-flags to DAG nodes (NFC)

This patch adds the minimum plumbing necessary to use IR-level
fast-math-flags (FMF) in the backend without actually using
them for anything yet

propagate IR-level fast-math-flags to DAG nodes (NFC)

This patch adds the minimum plumbing necessary to use IR-level
fast-math-flags (FMF) in the backend without actually using
them for anything yet. This is a follow-on to:
http://reviews.llvm.org/rL235997

...which split the existing nsw / nuw / exact flags and FMF
into their own struct.

There are 2 structural changes here:

1. The main diff is that we're preparing to extend the optimization
flags to affect more than just binary SDNodes. Eg, IR intrinsics
( https://llvm.org/bugs/show_bug.cgi?id=21290 ) or non-binop nodes
that don't even exist in IR such as FMA, FNEG, etc.

2. The other change is that we're actually copying the FP fast-math-flags
from the IR instructions to SDNodes.

Differential Revision: http://reviews.llvm.org/D8900

llvm-svn: 236546

show more ...

fixed comments, blanks, nullptr; NFC

llvm-svn: 236086

move IR-level optimization flags into their own struct

This is a preliminary step to using the IR-level floating-point fast-math-flags in the SDAG (D8900).

In this patch, we introduce the optimizat

move IR-level optimization flags into their own struct

This is a preliminary step to using the IR-level floating-point fast-math-flags in the SDAG (D8900).

In this patch, we introduce the optimization flags as their own struct. As noted in the TODO comment,
we should eventually share this data between the IR passes and the backend.

We also switch the existing nsw / nuw / exact bit functionality of the BinaryWithFlagsSDNode class to
use the new struct.

The tradeoff is that instead of using the free but limited space of SDNode's SubclassData, we add a
data member to the subclass. This means we don't have to repeat all of the get/set methods per flag,
but we're potentially adding size to all nodes of this subclassi type.

In practice on 64-bit systems (measured on Linux and MacOS X), there is no size difference between an
SDNode and BinaryWithFlagsSDNode after this change: they're both 80 bytes. This means that we had at
least one free byte to play with due to struct alignment.

Differential Revision: http://reviews.llvm.org/D9325

llvm-svn: 235997

show more ...

Reapply r235977 "[DebugInfo] Add debug locations to constant SD nodes"

[DebugInfo] Add debug locations to constant SD nodes

This adds debug location to constant nodes of Selection DAG and updates
a

Reapply r235977 "[DebugInfo] Add debug locations to constant SD nodes"

[DebugInfo] Add debug locations to constant SD nodes

This adds debug location to constant nodes of Selection DAG and updates
all places that create constants to pass debug locations
(see PR13269).

Can't guarantee that all locations are correct, but in a lot of cases choice
is obvious, so most of them should be. At least all tests pass.

Tests for these changes do not cover everything, instead just check it for
SDNodes, ARM and AArch64 where it's easy to get incorrect locations on
constants.

This is not complete fix as FastISel contains workaround for wrong debug
locations, which drops locations from instructions on processing constants,
but there isn't currently a way to use debug locations from constants there
as llvm::Constant doesn't cache it (yet). Although this is a bit different
issue, not directly related to these changes.

Differential Revision: http://reviews.llvm.org/D9084

llvm-svn: 235989

show more ...

Revert "[DebugInfo] Add debug locations to constant SD nodes"

This breaks a test:
http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/23870

llvm-svn: 235987

[DebugInfo] Add debug locations to constant SD nodes

This adds debug location to constant nodes of Selection DAG and updates
all places that create constants to pass debug locations
(see PR13269).

[DebugInfo] Add debug locations to constant SD nodes

This adds debug location to constant nodes of Selection DAG and updates
all places that create constants to pass debug locations
(see PR13269).

Can't guarantee that all locations are correct, but in a lot of cases choice
is obvious, so most of them should be. At least all tests pass.

Tests for these changes do not cover everything, instead just check it for
SDNodes, ARM and AArch64 where it's easy to get incorrect locations on
constants.

This is not complete fix as FastISel contains workaround for wrong debug
locations, which drops locations from instructions on processing constants,
but there isn't currently a way to use debug locations from constants there
as llvm::Constant doesn't cache it (yet). Although this is a bit different
issue, not directly related to these changes.

Differential Revision: http://reviews.llvm.org/D9084

llvm-svn: 235977

show more ...

Masked gather and scatter: Added code for SelectionDAG.
All other patches, including tests will follow.

http://reviews.llvm.org/D7665

llvm-svn: 235970

move helper function closer to use; NFC

llvm-svn: 234344

[DAGCombiner] Add support for TRUNCATE + FP_EXTEND vector constant folding

This patch adds supports for the vector constant folding of TRUNCATE and FP_EXTEND instructions and tidies up the SINT_TO_F

[DAGCombiner] Add support for TRUNCATE + FP_EXTEND vector constant folding

This patch adds supports for the vector constant folding of TRUNCATE and FP_EXTEND instructions and tidies up the SINT_TO_FP and UINT_TO_FP instructions to match.

It also moves the vector constant folding for the FNEG and FABS instructions to use the DAG.getNode() functionality like the other unary instructions.

Differential Revision: http://reviews.llvm.org/D8593

llvm-svn: 233224

show more ...

[DAGCombiner] Add a shuffle mask commutation helper function. NFCI.

We have an increasing number of cases where we are creating commuted shuffle masks - all implementing nearly the same code.

This

[DAGCombiner] Add a shuffle mask commutation helper function. NFCI.

We have an increasing number of cases where we are creating commuted shuffle masks - all implementing nearly the same code.

This patch adds a static helper function - ShuffleVectorSDNode::commuteMask() and replaces a number of cases to use it.

Differential Revision: http://reviews.llvm.org/D8139

llvm-svn: 231581

show more ...

don't repeat class / function / variable names in comments; NFC

llvm-svn: 231292

Remove the explicit SDNodeIterator::operator= in favor of the implicit default

There doesn't seem to be any need to assert that iterator assignment is
between iterators over the same node - if you w

Remove the explicit SDNodeIterator::operator= in favor of the implicit default

There doesn't seem to be any need to assert that iterator assignment is
between iterators over the same node - if you want to reuse an iterator
variable to iterate another node, that's perfectly acceptable. Just
don't mix comparisons between iterators into disjoint sequences, as
usual.

llvm-svn: 231138

show more ...

Revert "Remove the explicit SDNodeIterator::operator= in favor of the implicit default"

Accidentally committed a few more of these cleanup changes than
intended. Still breaking these out & tidying t

Revert "Remove the explicit SDNodeIterator::operator= in favor of the implicit default"

Accidentally committed a few more of these cleanup changes than
intended. Still breaking these out & tidying them up.

This reverts commit r231135.

llvm-svn: 231136

show more ...

Remove the explicit SDNodeIterator::operator= in favor of the implicit default

There doesn't seem to be any need to assert that iterator assignment is
between iterators over the same node - if you w

Remove the explicit SDNodeIterator::operator= in favor of the implicit default

There doesn't seem to be any need to assert that iterator assignment is
between iterators over the same node - if you want to reuse an iterator
variable to iterate another node, that's perfectly acceptable. Just
don't mix comparisons between iterators into disjoint sequences, as
usual.

llvm-svn: 231135

show more ...

Removing LLVM_DELETED_FUNCTION, as MSVC 2012 was the last reason for requiring the macro. NFC; LLVM edition.

llvm-svn: 229340

Removing LLVM_EXPLICIT, as MSVC 2012 was the last reason for requiring the macro. NFC; LLVM edition.

llvm-svn: 229335

Move DebugLocs around instead of copying.

llvm-svn: 228491

Fixed a bug in type legalizer for masked load/store intrinsics.
The problem occurs when after vectorization we have type
<2 x i32>. This type is promoted to <2 x i64> and then requires
additional eff

Fixed a bug in type legalizer for masked load/store intrinsics.
The problem occurs when after vectorization we have type
<2 x i32>. This type is promoted to <2 x i64> and then requires
additional efforts for expanding loads and truncating stores.
I added EXPAND / TRUNCATE attributes to the masked load/store
SDNodes. The code now contains additional shuffles.
I've prepared changes in the cost estimation for masked memory
operations, it will be submitted separately.

llvm-svn: 226808

show more ...