|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| | This patch moves the isInlineViable function from the InlineAlways pass into
the InlineCostAnalyzer and then changes the InlineCost computation to use that
simple check for always-inline functions. All the special-case checks for
AlwaysInline in the CallAnalyzer can then go away.
llvm-svn: 168300 | 
| | 
| 
| 
| 
| 
| | removed in commit 168035, but I missed this bit).
llvm-svn: 168292 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | operands of the expression being written was wrongly thought to be reusable as
an inner node of the expression resulting in it turning up as both an inner node
*and* a leaf, creating a cycle in the def-use graph.  This would have caused the
verifier to blow up if things had gotten that far, however it managed to provoke
an infinite loop first.
llvm-svn: 168291 | 
| | 
| 
| 
| | llvm-svn: 168280 | 
| | 
| 
| 
| 
| 
| | edge table memory.
llvm-svn: 168259 | 
| | 
| 
| 
| 
| 
| 
| 
| | example: *dst++ = *src++).
At the moment we still require to have an integer induction variable (for example: i++).
llvm-svn: 168231 | 
| | 
| 
| 
| 
| 
| | is narrower than the stored value. rdar://12713675
llvm-svn: 168227 | 
| | 
| 
| 
| | llvm-svn: 168196 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | replaced by this patch is equivalent to the new logic, but you'd be wrong, and
that's exactly where the bug was.  There's a similar bug in instsimplify which
manifests itself as instsimplify failing to simplify this, rather than doing it
wrong, see next commit.
llvm-svn: 168181 | 
| | 
| 
| 
| 
| 
| | Patch by Pekka Jääskeläinen!
llvm-svn: 168176 | 
| | 
| 
| 
| 
| 
| 
| 
| | of the code that deals with divs.
Thanks to Paul Redmond for catching this while reviewing the code.
llvm-svn: 168142 | 
| | 
| 
| 
| | llvm-svn: 168058 | 
| | 
| 
| 
| | llvm-svn: 168057 | 
| | 
| 
| 
| | llvm-svn: 168049 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | For global variables that get the same value stored into them
everywhere, GlobalOpt will replace them with a constant. The problem is
that a thread-local GlobalVariable looks like one value (the address of
the TLS var), but is different between threads.
This patch introduces Constant::isThreadDependent() which returns true
for thread-local variables and constants which depend on them (e.g. a GEP
into a thread-local array), and teaches GlobalOpt not to track such
values.
llvm-svn: 168037 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | the utility for extracting a chain of operations from the IR, thought that it
might as well combine any constants it came across (rather than just returning
them along with everything else).  On the other hand, the factorization code
would like to see the individual constants (this is quite reasonable: it is
much easier to pull a factor of 3 out of 2*3 than it is to pull it out of 6;
you may think 6/3 isn't so hard, but due to overflow it's not as easy to undo
multiplications of constants as it may at first appear).  This patch therefore
makes LinearizeExprTree stupider: it now leaves optimizing to the optimization
part of reassociate, and sticks to just analysing the IR.
llvm-svn: 168035 | 
| | 
| 
| 
| 
| 
| | [-Wdocumentation]
llvm-svn: 168013 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | For now, this uses 8 on-stack elements. I'll need to do some profiling
to see if this is the best number.
Pointed out by Jakob in post-commit review.
llvm-svn: 167966 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Iterating over the children of each node in the potential vectorization
plan must happen in a deterministic order (because it affects which children
are erased when two children conflict). There was no need for this data
structure to be a map in the first place, so replacing it with a vector
is a small change.
I believe that this was the last remaining instance if iterating over the
elements of a Dense* container where the iteration order could matter.
There are some remaining iterations over std::*map containers where the order
might matter, but so long as the Value* for instructions in a block increase
with the order of the instructions in the block (or decrease) monotonically,
then this will appear to be deterministic.
llvm-svn: 167942 | 
| | 
| 
| 
| | llvm-svn: 167928 | 
| | 
| 
| 
| | llvm-svn: 167892 | 
| | 
| 
| 
| 
| 
| | are created (during function inlining)
llvm-svn: 167821 | 
| | 
| 
| 
| | llvm-svn: 167817 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This patch migrates the math library call simplifications from the
simplify-libcalls pass into the instcombine library call simplifier.
I have typically migrated just one simplifier at a time, but the math
simplifiers are interdependent because:
   1. CosOpt, PowOpt, and Exp2Opt all depend on UnaryDoubleFPOpt.
   2. CosOpt, PowOpt, Exp2Opt, and UnaryDoubleFPOpt all depend on
      the option -enable-double-float-shrink.
These two factors made migrating each of these simplifiers individually
more of a pain than it would be worth.  So, I migrated them all together.
llvm-svn: 167815 | 
| | 
| 
| 
| 
| 
| 
| 
| | Don't choose a vectorization plan containing only shuffles and
vector inserts/extracts. Due to inperfections in the cost model,
these can lead to infinite recusion.
llvm-svn: 167811 | 
| | 
| 
| 
| | llvm-svn: 167787 | 
| | 
| 
| 
| 
| 
| 
| 
| | This fixes another infinite recursion case when using target costs.
We can only replace insert element input chains that are pure (end
with inserting into an undef).
llvm-svn: 167784 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | The old checking code, which assumed that input shuffles and insert-elements
could always be folded (and thus were free) is too simple.
This can only happen in special circumstances.
Using the simple check caused infinite recursion.
llvm-svn: 167750 | 
| | 
| 
| 
| 
| 
| 
| | The pass would previously assert when trying to compute the cost of
compare instructions with illegal vector types (like struct pointers).
llvm-svn: 167743 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Reassociate pass.
The assertion is trigged when the Reassociater tries to transform expression
     ... + 2 * n * 3 + 2 * m + ...
  into:
     ... + 2 * (n*3 + m).
In the process of the transformation, a helper routine folds the constant 2*3 into 6,
confusing optimizer which is trying the to eliminate the common factor 2, and cannot
find 2 any more. 
Review is pending. But I'd like commit first in order to help those who are waiting 
for this fix. 
llvm-svn: 167740 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | This fixes a bug where shuffles were being fused such that the
resulting input types were not legal on the target. This would
occur only when both inputs and dependencies were also foldable
operations (such as other shuffles) and there were other connected
pairs in the same block.
llvm-svn: 167731 | 
| | 
| 
| 
| | llvm-svn: 167729 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The library call simplifier folds memcmp calls with all constant arguments
to a constant.  For example:
  memcmp("foo", "foo", 3) ->  0
  memcmp("hel", "foo", 3) ->  1
  memcmp("foo", "hel", 3) -> -1
The folding is implemented in terms of the system memcmp that LLVM gets
linked with.  It currently just blindly uses the value returned from
the system memcmp as the folded constant.
This patch normalizes the values returned from the system memcmp to
(-1, 0, 1) so that we get consistent results across multiple platforms.
The test cases were adjusted accordingly.
llvm-svn: 167726 | 
| | 
| 
| 
| 
| 
| | checking for globals of specified types. Tests for this behavior will go to ASan test suite in compiler-rt.
llvm-svn: 167725 | 
| | 
| 
| 
| | llvm-svn: 167698 | 
| | 
| 
| 
| 
| 
| 
| | This patch migrates the memset optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
llvm-svn: 167689 | 
| | 
| 
| 
| 
| 
| 
| | This patch migrates the memmove optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
llvm-svn: 167687 | 
| | 
| 
| 
| 
| 
| 
| | This patch migrates the memcpy optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
llvm-svn: 167686 | 
| | 
| 
| 
| | llvm-svn: 167684 | 
| | 
| 
| 
| 
| 
| 
| | This patch migrates the memcmp optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
llvm-svn: 167683 | 
| | 
| 
| 
| 
| 
| 
| | This patch migrates the strstr optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
llvm-svn: 167682 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | In some cases the library call simplifier may need to replace instructions
other than the library call being simplified.  In those cases it may be
necessary for clients of the simplifier to override how the replacements
are actually done.  As such, a new overrideable method for replacing
instructions was added to LibCallSimplifier.
A new subclass of LibCallSimplifier is also defined which overrides
the instruction replacement method.  This is because the instruction
combiner defines its own replacement method which updates the worklist
when instructions are replaced.
llvm-svn: 167681 | 
| | 
| 
| 
| 
| 
| 
| | This patch migrates the strcspn optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
llvm-svn: 167675 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Several of the simplifiers migrated from the simplify-libcalls pass to
the instcombine pass were not correctly checking the target library
information to gate the simplifications.  This patch ensures that the
check is made.
llvm-svn: 167660 | 
| | 
| 
| 
| | llvm-svn: 167615 | 
| | 
| 
| 
| | llvm-svn: 167612 | 
| | 
| 
| 
| 
| 
| 
| | If the arrays are found to be disjoint then we run the vectorized version of
the loop. If they are not, we run the scalar code.
llvm-svn: 167608 | 
| | 
| 
| 
| 
| 
| 
| | This patch migrates the strspn optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
llvm-svn: 167568 | 
| | 
| 
| 
| 
| 
| | is available.
llvm-svn: 167552 | 
| | 
| 
| 
| 
| 
| | interface function is being redefined. Before this fix asan asserts)
llvm-svn: 167529 |