| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 167912
|
| |
|
|
|
|
| |
SETCC node would be illegal.
llvm-svn: 167344
|
| |
|
|
| |
llvm-svn: 167200
|
| |
|
|
|
|
|
|
|
| |
checks to avoid performing compile-time arithmetic on PPCDoubleDouble.
Now that APFloat supports arithmetic on PPCDoubleDouble, those checks
are no longer needed, and we can treat the type like any other.
llvm-svn: 166958
|
| |
|
|
|
|
|
|
| |
- If more than 1 elemennts are defined and target supports the vectorized
conversion, use the vectorized one instead to reduce the strength on
conversion operation.
llvm-svn: 166546
|
| |
|
|
| |
llvm-svn: 166531
|
| |
|
|
| |
llvm-svn: 166519
|
| |
|
|
| |
llvm-svn: 166260
|
| |
|
|
|
|
|
|
| |
fact that one was dependent on the other.
rdar://12513091
llvm-svn: 166196
|
| |
|
|
|
|
|
|
| |
- Folding (trunc (concat ... X )) to (concat ... (trunc X) ...) is valid
when '...' are all 'undef's.
- r166125 relies on this transformation.
llvm-svn: 166155
|
| |
|
|
|
|
| |
- In general, it's unsafe for this transformation.
llvm-svn: 166135
|
| |
|
|
|
|
|
|
| |
- If the extracted vector has the same type of all vectored being concatenated
together, it should be simplified directly into v_i, where i is the index of
the element being extracted.
llvm-svn: 166125
|
| |
|
|
| |
llvm-svn: 166049
|
| |
|
|
|
|
|
|
| |
This class is used by LSR and a number of places in the codegen.
This is the first step in de-coupling LSR from TLI, and creating
a new interface in between them.
llvm-svn: 165455
|
| |
|
|
| |
llvm-svn: 165402
|
| |
|
|
| |
llvm-svn: 165331
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 165321
|
| |
|
|
| |
llvm-svn: 165267
|
| |
|
|
|
|
|
|
|
|
|
| |
load and
multiple stores with a single load. We create the wide loads and stores (and their chains)
before we remove the scalar loads and stores and fix the DAG chain. We attempted to merge
loads with a different chain. When that happened, the assumption that it is safe to RAUW
broke and a cycle was introduced.
llvm-svn: 165148
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimization
is not profitable in many cases because modern processors perform multiple stores
in parallel and merging stores prior to merging requires extra work. We handle two main cases:
1. Store of multiple consecutive constants:
q->a = 3;
q->4 = 5;
In this case we store a single legal wide integer.
2. Store of multiple consecutive loads:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
In this case we load/store either ilegal vector registers or legal wide integer registers.
llvm-svn: 165125
|
| |
|
|
| |
llvm-svn: 164911
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work. We only handle these cases:
1. Consecutive stores where the values and consecutive loads. For example:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
2. Consecutive stores where the values are constants. Foe example:
q->a = 4;
q->b = 5;
llvm-svn: 164910
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
buildbots. Original commit message:
A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work. We only handle these cases:
1. Consecutive stores where the values and consecutive loads. For example:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
2. Consecutive stores where the values are constants. Foe example:
q->a = 4;
q->b = 5;
llvm-svn: 164890
|
| |
|
|
|
|
| |
operators to end of preceding line. No functional change intended.
llvm-svn: 164887
|
| |
|
|
|
|
| |
the varying arguments. No functional change.
llvm-svn: 164886
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work. We only handle these cases:
1. Consecutive stores where the values and consecutive loads. For example:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
2. Consecutive stores where the values are constants. Foe example:
q->a = 4;
q->b = 5;
llvm-svn: 164885
|
| |
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767
llvm-svn: 164768
|
| |
|
|
| |
llvm-svn: 164767
|
| |
|
|
| |
llvm-svn: 164297
|
| |
|
|
|
|
|
|
|
|
|
| |
bitcast of fneg to integers
by xoring the high-bit. This fails if the source operand is a vector because we need to negate
each of the elements in the vector.
Fix rdar://12281066 PR13813.
llvm-svn: 163802
|
| |
|
|
|
|
| |
Factor similar code out of FNEG DAG combiner.
llvm-svn: 163587
|
| |
|
|
|
|
| |
concat_vectors, and a followup bug with SelectionDAG::getNode() creating nodes with invalid types.
llvm-svn: 163511
|
| |
|
|
| |
llvm-svn: 163483
|
| |
|
|
| |
llvm-svn: 163256
|
| |
|
|
|
|
| |
types. The previous code was making the assumption that the length of the bitmask returned by isConstantSplat was equal to the size of the vector type. Now we first make sure that the splat value has at least the length of the vector lane type, then we only use as many fields as we have available in the splat value.
llvm-svn: 163203
|
| |
|
|
|
|
| |
fast-math mode.
llvm-svn: 163051
|
| |
|
|
| |
llvm-svn: 163049
|
| |
|
|
|
|
| |
constants. This is only enabled in unsafe FP math mode, since it does not preserve rounding effects for all such constants.
llvm-svn: 162956
|
| |
|
|
|
|
| |
approach. We need to insert some valid TRANCATE node here.
llvm-svn: 162354
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DAGCombiner tries to optimise a BUILD_VECTOR by checking if it
consists purely of get_vector_elts from one or two source vectors. If
so, it either makes a concat_vectors node or a shufflevector node.
However, it doesn't check the element type width of the underlying
vector, so if you have this sequence:
Node0: v4i16 = ...
Node1: i32 = extract_vector_elt Node0
Node2: i32 = extract_vector_elt Node0
Node3: v16i8 = BUILD_VECTOR Node1, Node2, ...
It will attempt to:
Node0: v4i16 = ...
NewNode1: v16i8 = concat_vectors Node0, ...
Where this is actually invalid because the element width is completely
different. This causes an assertion failure on DAG legalization stage.
Fix:
If output item type of BUILD_VECTOR differs from input item type.
Make concat_vectors based on input element type and then bitcast it to the output vector type. So the case described above will transformed to:
Node0: v4i16 = ...
NewNode1: v8i16 = concat_vectors Node0, ...
NewNode2: v16i8 = bitcast NewNode1
llvm-svn: 162195
|
| |
|
|
|
|
| |
various rounding modes. Use this to implement SelectionDAG constant folding of FFLOOR, FCEIL, and FTRUNC.
llvm-svn: 161807
|
| |
|
|
| |
llvm-svn: 161110
|
| |
|
|
|
|
|
|
|
|
| |
that do not support it (X86 does not lower select_cc).
PR: 13428
Together with Michael Kuperstein <michael.m.kuperstein@intel.com>
llvm-svn: 160619
|
| |
|
|
| |
llvm-svn: 160475
|
| |
|
|
|
|
| |
instcombine transformation.
llvm-svn: 160387
|
| |
|
|
|
|
|
|
|
| |
Add a micro-optimization to getNode of CONCAT_VECTORS when both operands are undefs.
Can't find a testcase for this because VECTOR_SHUFFLE already handles undef operands, but Duncan suggested that we add this.
Together with Michael Kuperstein <michael.m.kuperstein@intel.com>
llvm-svn: 160229
|
| |
|
|
|
|
|
|
| |
single undef.
The unoptimized concat_vectors isd prevented the canonicalization of the vector_shuffle node.
llvm-svn: 160221
|
| |
|
|
|
|
|
|
| |
an MVT::i1, i.e. before type legalization.
This is a speculative fix for a problem on Mips reported by Akira Hatanaka.
llvm-svn: 160036
|
| |
|
|
|
|
|
|
|
| |
multiple scalars and insert them into a vector. Next, we shuffle the elements
into the correct places, as before.
Also fix a small dagcombine bug in SimplifyBinOpWithSameOpcodeHands, when the
migration of bitcasts happened too late in the SelectionDAG process.
llvm-svn: 159991
|
| |
|
|
|
|
|
|
| |
move, since there are only two possible values.
Previously, this would become an integer extension operation, followed by a real integer->float conversion.
llvm-svn: 159957
|