|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| | APFloat::isFiniteNonZero.
Turns out all the references were in llvm and not in clang.
llvm-svn: 184356 | 
| | 
| 
| 
| | llvm-svn: 183461 | 
| | 
| 
| 
| | llvm-svn: 183439 | 
| | 
| 
| 
| 
| 
| 
| 
| | little bit."
This reverts commit 183328. It caused pr16244 and broke the bots.
llvm-svn: 183422 | 
| | 
| 
| 
| | llvm-svn: 183363 | 
| | 
| 
| 
| | llvm-svn: 183360 | 
| | 
| 
| 
| | llvm-svn: 183328 | 
| | 
| 
| 
| | llvm-svn: 183167 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | index greater than the size of the vector is invalid. The shuffle may be
shrinking the size of the vector. Fixes a crash!
Also drop the maximum recursion depth of the safety check for this
optimization to five.
llvm-svn: 183080 | 
| | 
| 
| 
| 
| 
| | Patch by Andrea Di Biagio.
llvm-svn: 183005 | 
| | 
| 
| 
| 
| 
| | insertelement instructions.
llvm-svn: 182976 | 
| | 
| 
| 
| 
| 
| | PR/16177
llvm-svn: 182919 | 
| | 
| 
| 
| | llvm-svn: 182909 | 
| | 
| 
| 
| | llvm-svn: 182680 | 
| | 
| 
| 
| | llvm-svn: 182640 | 
| | 
| 
| 
| 
| 
| 
| 
| | as the BinaryOperator, *not* in the block where the IRBuilder is currently
inserting into. Fixes a bug where scalarizePHI would create instructions
that would not dominate all uses.
llvm-svn: 182639 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The earlier change list introduced the following inst combines:
B * (uitofp i1 C) —> select C, B, 0
A * (1 - uitofp i1 C) —> select C, 0, A
select C, 0, B + select C, A, 0 —> select C, A, B
Together these 3 changes would simplify :
A * (1 - uitofp i1 C) + B * uitofp i1 C 
down to :
select C, B, A
In practice we found that the first two substitutions can have a
negative effect on performance, because they reduce opportunities to
use FMA contractions; between the two options FMAs are often the
better choice.  This change list amends the previous one to enable
just these inst combines:
select C, B, 0 + select C, 0, A —> select C, B, A
A * (1 - uitofp i1 C) + B * uitofp i1 C —> select C, B, A
llvm-svn: 182499 | 
| | 
| 
| 
| | llvm-svn: 182164 | 
| | 
| 
| 
| | llvm-svn: 181848 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | There are two transforms in visitUrem that conflict with each other.
*) One, if a divisor is a power of two, subtracts one from the divisor
   and turns it into a bitwise-and.
*) The other unwraps both operands if they are surrounded by zext
   instructions.
Flipping the order allows the subtraction to go beneath the sign
extension.
llvm-svn: 181668 | 
| | 
| 
| 
| 
| 
| 
| | Use isKnownToBeAPowerOfTwo in visitUrem so that we may more aggressively
fold away urem instructions.
llvm-svn: 181661 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | The shift amount may be larger than the type leading to undefined behavior.
Limit the transform to constant shift amounts. While there update the bits to
clear in the result which may enable additional optimizations.
PR15959.
llvm-svn: 181604 | 
| | 
| 
| 
| 
| 
| | PR15952.
llvm-svn: 181586 | 
| | 
| 
| 
| 
| 
| 
| | That's obviously wrong. Conservatively restrict it to the sign bit, which
matches the original intention of this analysis. Fixes PR15940.
llvm-svn: 181518 | 
| | 
| 
| 
| | llvm-svn: 181249 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | A * (1 - (uitofp i1 C)) -> select C, 0, A
B * (uitofp i1 C) -> select C, B, 0
select C, 0, A + select C, B, 0 -> select C, B, A
These come up in code that has been hand-optimized from a select to a linear blend, 
on platforms where that may have mattered. We want to undo such changes 
with the following transform:
A*(1 - uitofp i1 C) + B*(uitofp i1 C) -> select C, A, B
llvm-svn: 181216 | 
| | 
| 
| 
| 
| 
| | Thanks Nick Lewycky for pointing this out.
llvm-svn: 181177 | 
| | 
| 
| 
| 
| 
| 
| 
| | constructor enables
Patch by Robert Wilhelm.
llvm-svn: 181138 | 
| | 
| 
| 
| | llvm-svn: 181082 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | the things, and renames it to CBindingWrapping.h.  I also moved 
CBindingWrapping.h into Support/.
This new file just contains the macros for defining different wrap/unwrap 
methods.
The calls to those macros, as well as any custom wrap/unwrap definitions 
(like for array of Values for example), are put into corresponding C++ 
headers.
Doing this required some #include surgery, since some .cpp files relied 
on the fact that including Wrap.h implicitly caused the inclusion of a 
bunch of other things.
This also now means that the C++ headers will include their corresponding 
C API headers; for example Value.h must include llvm-c/Core.h.  I think 
this is harmless, since the C API headers contain just external function 
declarations and some C types, so I don't believe there should be any 
nasty dependency issues here.
llvm-svn: 180881 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This reverts commit r180802
There's ongoing discussion about whether this is the right place to make
this transformation. Reverting for now while we figure it out.
llvm-svn: 180834 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Always fold a shuffle-of-shuffle into a single shuffle when there's only one
input vector in the first place. Continue to be more conservative when there's
multiple inputs.
rdar://13402653
PR15866
llvm-svn: 180802 | 
| | 
| 
| 
| 
| 
| 
| | Differences in bitwidth between X and Y could exist even if C1 and C2 have
the same Log2 representation.
llvm-svn: 180779 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This fixes the optimization introduced in r179748 and reverted in r179750.
While the optimization was sound, it did not properly respect differences in
bit-width.
llvm-svn: 180777 | 
| | 
| 
| 
| 
| 
| 
| | or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.
llvm-svn: 180063 | 
| | 
| 
| 
| 
| 
| | extract(cast) is transformed to cast(extract). It uses the Builder class as before. In addition the result node is added to the Worklist, so all the previous extract users will become the new scalar cast users.
llvm-svn: 180045 | 
| | 
| 
| 
| | llvm-svn: 179826 | 
| | 
| 
| 
| 
| 
| | limitation that extract is promoted over a cast only if the cast has only one use.
llvm-svn: 179786 | 
| | 
| 
| 
| 
| 
| | it has only 2 uses: one to promote the vector phi in a loop and the other use is an extract operation of one element at a constant location.
llvm-svn: 179783 | 
| | 
| 
| 
| 
| 
| | It is causing stage2 builds to fail, let's get them running again.
llvm-svn: 179750 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Simplify:
(select (icmp eq (and X, C1), 0), Y, (or Y, C2))
Into:
(or (shl (and X, C1), C3), y)
Where:
C3 = Log(C2) - Log(C1)
If:
C1 and C2 are both powers of two
llvm-svn: 179748 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | One performs: (X == 13 | X == 14) -> X-13 <u 2
The other: (A == C1 || A == C2) -> (A & ~(C1 ^ C2)) == C1
The problem is that there are certain values of C1 and C2 that
trigger both transforms but the first one blocks out the second,
this generates suboptimal code.
Reordering the transforms should be better in every case and
allows us to do interesting stuff like turn:
  %shr = lshr i32 %X, 4
  %and = and i32 %shr, 15
  %add = add i32 %and, -14
  %tobool = icmp ne i32 %add, 0
into:
  %and = and i32 %X, 240
  %tobool = icmp ne i32 %and, 224
llvm-svn: 179493 | 
| | 
| 
| 
| 
| 
| | Fixes PR15737.
llvm-svn: 179417 | 
| | 
| 
| 
| 
| 
| 
| 
| | The transform will execute like so:
(A & ~B) == 0 --> (A & B) != 0
(A & ~B) != 0 --> (A & B) == 0
llvm-svn: 179386 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Allows LLVM to optimize sequences like the following:
%add = add nsw i32 %x, 1
%cmp = icmp sgt i32 %add, %y
into:
%cmp = icmp sge i32 %x, %y
as well as:
%add1 = add nsw i32 %x, 20
%add2 = add nsw i32 %y, 57
%cmp = icmp sge i32 %add1, %add2
into:
%add = add nsw i32 %y, 37
%cmp = icmp sle i32 %cmp, %x
llvm-svn: 179316 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | When trying to collapse sequences of insertelement/extractelement
instructions into single shuffle instructions, there is one specific
case where the Instruction Combiner wrongly updates the resulting
Mask of shuffle indexes.
The problem is in function CollectShuffleElments.
If we have a sequence of insert/extract element instructions
like the one below:
  %tmp1 = extractelement <4 x float> %LHS, i32 0
  %tmp2 = insertelement <4 x float> %RHS, float %tmp1, i32 1
  %tmp3 = extractelement <4 x float> %RHS, i32 2
  %tmp4 = insertelement <4 x float> %tmp2, float %tmp3, i32 3
Where:
  . %RHS will have a mask of [4,5,6,7]
  . %LHS will have a mask of [0,1,2,3]
The Mask of shuffle indexes is wrongly computed to [4,1,6,7]
instead of [4,0,6,7].
When analyzing %tmp2 in order to compute the Mask for the
resulting shuffle instruction, the algorithm forgets to update
the mask index at position 1 with the index associated to the
element extracted from %LHS by instruction %tmp1.
Patch by Andrea DiBiagio!
llvm-svn: 179291 | 
| | 
| 
| 
| | llvm-svn: 178915 | 
| | 
| 
| 
| | llvm-svn: 178208 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The OptimizeIntToFloatBitCast converts shift-truncate sequences
into extractelement operations.  The computation of the element
index to be used in the resulting operation is currently only
correct for little-endian targets.
This commit fixes the element index computation to be correct
for big-endian targets as well.  If the target byte order is
unknown, the optimization cannot be performed at all.
llvm-svn: 178031 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The problem is that the code mistakenly took for granted that following constructor 
is able to create an APFloat from a *SIGNED* integer:
   
  APFloat::APFloat(const fltSemantics &ourSemantics, integerPart value)
rdar://13486998
llvm-svn: 177906 |