|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| | llvm-svn: 155309 | 
| | 
| 
| 
| 
| 
| | widening of vectors.
llvm-svn: 155296 | 
| | 
| 
| 
| 
| 
| 
| 
| | The X86 target is editing the selection DAG while isel is selecting
nodes following a topological ordering. When the DAG hacking triggers
CSE, nodes can be deleted and bad things happen.
llvm-svn: 155257 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Now that multiple DAGUpdateListeners can be active at the same time,
ISelPosition can become a local variable in DoInstructionSelection.
We simply register an ISelUpdater with CurDAG while ISelPosition exists.
llvm-svn: 155249 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Instead of passing listener pointers to RAUW, let SelectionDAG itself
keep a linked list of interested listeners.
This makes it possible to have multiple listeners active at once, like
RAUWUpdateListener was already doing. It also makes it possible to
register listeners up the call stack without controlling all RAUW calls
below.
DAGUpdateListener uses an RAII pattern to add itself to the SelectionDAG
list of active listeners.
llvm-svn: 155248 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | transformation:
(X op C1) ^ C2 --> (X op C1) & ~C2 iff (C1&C2) == C2
should be done.  
This change has been tested:
 Using a debug+asserts build:
   on the specific test case that brought this bug to light
   make check-all
   lnt nt
   using this clang to build a release version of clang
 Using the release+asserts clang-with-clang build:
   on the specific test case that brought this bug to light
   make check-all
   lnt nt
Checking in because Evan wants it checked in.  Test case forthcoming after
scrubbing.
llvm-svn: 154955 | 
| | 
| 
| 
| | llvm-svn: 154786 | 
| | 
| 
| 
| 
| 
| | to the original type.
llvm-svn: 154764 | 
| | 
| 
| 
| 
| 
| 
| 
| | Fix a dagcombine optimization which assumes that the vsetcc result type is always
of the same size as the compared values. This is ture for SSE/AVX/NEON but not
for all targets.
llvm-svn: 154490 | 
| | 
| 
| 
| | llvm-svn: 154479 | 
| | 
| 
| 
| 
| 
| | intrinsic to an nodetype.
llvm-svn: 154478 | 
| | 
| 
| 
| 
| 
| | compiled code size a bit.
llvm-svn: 154473 | 
| | 
| 
| 
| 
| 
| 
| 
| | one-operand version of getNode() to the two-operand version, since it became a two-operand node at sound point.
Zap a testcase that this allows us to completely fold away.
llvm-svn: 154447 | 
| | 
| 
| 
| 
| 
| | multiplication by a denormal, and some tests checking that.
llvm-svn: 154431 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | don't elide the branch instruction if it's the only one in the block,
otherwise it's ok.
PR9796 and rdar://11215207
llvm-svn: 154417 | 
| | 
| 
| 
| | llvm-svn: 154414 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | always
of the same size as the compared values. This is ture for SSE/AVX/NEON but not
for all targets.
llvm-svn: 154397 | 
| | 
| 
| 
| 
| 
| | This fixes PR12516 and uncovers one weird problem in legalize (workarounded)
llvm-svn: 154394 | 
| | 
| 
| 
| | llvm-svn: 154378 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | legalizer always use the DAG entry node. This is wrong when the libcall is
emitted as a tail call since it effectively folds the return node. If
the return node's input chain is not the entry (i.e. call, load, or store)
use that as the tail call input chain.
PR12419
rdar://9770785
rdar://11195178
llvm-svn: 154370 | 
| | 
| 
| 
| 
| 
| | not fit in a i64.
llvm-svn: 154364 | 
| | 
| 
| 
| 
| 
| | GOT if jump table uses 64-bit gp-relative relocation.
llvm-svn: 154341 | 
| | 
| 
| 
| | llvm-svn: 154322 | 
| | 
| 
| 
| 
| 
| | some checks to allow better early out.
llvm-svn: 154309 | 
| | 
| 
| 
| | llvm-svn: 154308 | 
| | 
| 
| 
| | llvm-svn: 154307 | 
| | 
| 
| 
| 
| 
| | happen.
llvm-svn: 154305 | 
| | 
| 
| 
| | llvm-svn: 154299 | 
| | 
| 
| 
| | llvm-svn: 154297 | 
| | 
| 
| 
| 
| 
| 
| 
| | when -ffast-math, i.e. don't just always do it if the reciprocal can
be formed exactly.  There is already an IR level transform that does
that, and it does it more carefully.
llvm-svn: 154296 | 
| | 
| 
| 
| 
| 
| | width and the input vector widths don't match. No need to check the min and max are in range before calculating the start index. The range check after having the start index is sufficient. Also no need to check for an extract from the beginning differently.
llvm-svn: 154295 | 
| | 
| 
| 
| 
| 
| 
| 
| | in TargetLowering. There was already a FIXME about this location being
odd. The interface is simplified as a consequence. This will also make
it easier to change TLS models when compiling with PIE.
llvm-svn: 154292 | 
| | 
| 
| 
| 
| 
| | remove patterns for selecting the intrinsic. Similar was already done for avx1.
llvm-svn: 154272 | 
| | 
| 
| 
| | llvm-svn: 154267 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | shuffle node because it could introduce new shuffle nodes that were not
   supported efficiently by the target.
2. Add a more restrictive shuffle-of-shuffle optimization for cases where the
   second shuffle reverses the transformation of the first shuffle.
llvm-svn: 154266 | 
| | 
| 
| 
| 
| 
| 
| 
| | reciprocal if converting to the reciprocal is exact.  Do it even if inexact
if -ffast-math.  This substantially speeds up ac.f90 from the polyhedron
benchmarks.
llvm-svn: 154265 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | LSR always tries to make the ICmp in the loop latch use the incremented
induction variable. This allows the induction variable to be kept in a
single register.
When the induction variable limit is equal to the stride,
SimplifySetCC() would break LSR's hard work by transforming:
   (icmp (add iv, stride), stride) --> (cmp iv, 0)
This forced us to use lea for the IC update, preventing the simpler
incl+cmp.
<rdar://problem/7643606>
<rdar://problem/11184260>
llvm-svn: 154119 | 
| | 
| 
| 
| 
| 
| | during instruction selection.
llvm-svn: 154113 | 
| | 
| 
| 
| | llvm-svn: 154039 | 
| | 
| 
| 
| 
| 
| 
| 
| | This allows us to keep passing reduced masks to SimplifyDemandedBits, but
know about all the bits if SimplifyDemandedBits fails. This allows instcombine
to simplify cases like the one in the included testcase.
llvm-svn: 154011 | 
| | 
| 
| 
| | llvm-svn: 153996 | 
| | 
| 
| 
| 
| 
| | enum values
llvm-svn: 153984 | 
| | 
| 
| 
| 
| 
| | would crash if it encountered a 1 element VSELECT.  Solution is slightly more complicated than just creating a SELET as we have to mask or sign extend the vector condition if it had different boolean contents from the scalar condition.  Fixes <rdar://problem/11178095>
llvm-svn: 153976 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | When folding X == X we need to check getBooleanContents() to determine if the
result is a vector of ones or a vector of negative ones. 
I tried creating a test case, but the problem seems to only be exposed on a
much older version of clang (around r144500).
rdar://10923049
llvm-svn: 153966 | 
| | 
| 
| 
| 
| 
| | operations, and prevent the DAGCombiner from turning them into bitwise operations if they do.
llvm-svn: 153901 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | shuffles.
Do not try to optimize swizzles of shuffles if the source shuffle has more than
a single user, except when the source shuffle is also a swizzle.
llvm-svn: 153864 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 1. Simplify xor/and/or (bitcast(A), bitcast(B)) -> bitcast(op (A,B))
   (and also scalar_to_vector).
2. Xor/and/or are indifferent to the swizzle operation (shuffle of one src).
   Simplify xor/and/or (shuff(A), shuff(B)) -> shuff(op (A, B))
3. Optimize swizzles of shuffles:  shuff(shuff(x, y), undef) -> shuff(x, y).
4. Fix an X86ISelLowering optimization which was very bitcast-sensitive.
Code which was previously compiled to this:
movd    (%rsi), %xmm0
movdqa  .LCPI0_0(%rip), %xmm2
pshufb  %xmm2, %xmm0
movd    (%rdi), %xmm1
pshufb  %xmm2, %xmm1
pxor    %xmm0, %xmm1
pshufb  .LCPI0_1(%rip), %xmm1
movd    %xmm1, (%rdi)
ret
Now compiles to this:
movl    (%rsi), %eax
xorl    %eax, (%rdi)
ret
llvm-svn: 153848 | 
| | 
| 
| 
| 
| 
| 
| 
| | This is the CodeGen equivalent of r153747. I tested that there is not noticeable
performance difference with any combination of -O0/-O2 /-g when compiling
gcc as a single compilation unit.
llvm-svn: 153817 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | here but it has no other uses, then we have a problem. E.g.,
  int foo (const int *x) {
    char a[*x];
    return 0;
  }
If we assign 'a' a vreg and fast isel later on has to use the selection
DAG isel, it will want to copy the value to the vreg. However, there are
no uses, which goes counter to what selection DAG isel expects.
<rdar://problem/11134152>
llvm-svn: 153705 | 
| | 
| 
| 
| | llvm-svn: 153571 |