| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
before referencing them. rdar://12868039
llvm-svn: 170078
|
| |
|
|
|
|
| |
rdar://12838504
llvm-svn: 169951
|
| |
|
|
| |
llvm-svn: 169854
|
| |
|
|
| |
llvm-svn: 169843
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
try to reduce the width of this load, and would end up transforming:
(truncate (lshr (sextload i48 <ptr> as i64), 32) to i32)
to
(truncate (zextload i32 <ptr+4> as i64) to i32)
We lost the sext attached to the load while building the narrower i32
load, and replaced it with a zext because lshr always zext's the
results. Instead, bail out of this combine when there is a conflict
between a sextload and a zext narrowing. The rest of the DAG combiner
still optimize the code down to the proper single instruction:
movswl 6(...),%eax
Which is exactly what we wanted. Previously we read past the end *and*
missed the sign extension:
movl 6(...), %eax
llvm-svn: 169802
|
| |
|
|
| |
llvm-svn: 169727
|
| |
|
|
| |
llvm-svn: 169692
|
| |
|
|
|
|
| |
or all 0s. These cases can show up when vectors are split for legalizing. Fix some tests that were dependent on these cases not being combined.
llvm-svn: 169684
|
| |
|
|
|
|
|
| |
check if loads that happen in between stores alias with the first store in the
chain, only with the second store onwards.
llvm-svn: 169516
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
| |
|
|
| |
llvm-svn: 169111
|
| |
|
|
|
|
| |
loads do not alias.
llvm-svn: 168832
|
| |
|
|
| |
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
|