Commit Graph

4974 Commits

Author SHA1 Message Date
Richard Trieu
f31ecd3927 Removing an "if (!this)" check from two print methods. The condition will
never be true in a well-defined context.  The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210497 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-09 22:53:16 +00:00
Alp Toker
5396370ebb Remove old fenv.h workaround for a historic clang driver bug
Tested and works fine with clang using libstdc++.

All indications are that this was fixed some time ago and isn't a problem with
any clang version we support.

I've added a note in PR6907 which is still open for some reason.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210485 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-09 19:00:52 +00:00
Alp Toker
f4cf404837 Fold FEnv.h into the implementation
Support headers shouldn't use config.h definitions, and they should never be
undefined like this.

ConstantFolding.cpp was the only user of this facility and already includes
config.h for other math features, so it makes sense to move the checks there at
point of use.

(The implicit config.h was also quite dangerous -- removing the FEnv.h include
would have silently disabled math constant folding without causing any tests to
fail. Need to investigate -Wundef once the cleanup is done.)

This eliminates the last config.h include from LLVM headers, paving the way for
more consistent configuration checks.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210483 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-09 18:28:53 +00:00
Tobias Grosser
5e66eea5ba ScalarEvolution: Derive element size from the type of the loaded element
Before, we where looking at the size of the pointer type that specifies the
location from which to load the element. This did not make any sense at all.

This change fixes a bug in the delinearization where we failed to delinerize
certain load instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210435 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-08 19:21:20 +00:00
Tom Roeder
5d0f7af3dc Add a new attribute called 'jumptable' that creates jump-instruction tables for functions marked with this attribute.
It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables.

This also adds backend support for generating the jump-instruction tables on ARM and X86.
Note that since the jumptable attribute creates a second function pointer for a
function, any function marked with jumptable must also be marked with unnamed_addr.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210280 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-05 19:29:43 +00:00
Rafael Espindola
cfee6c49ea Add a Constant version of stripPointerCasts.
Thanks to rnk for the suggestion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210205 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-04 19:01:48 +00:00
Sebastian Pop
20b6ed3c9c implement missing SCEVDivision case
without this case we would end on an infinite recursion: the remainder is zero,
so Numerator - Remainder is equal to Numerator and so we would recursively ask
for the division of Numerator by Denominator.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209838 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-29 19:44:09 +00:00
Sebastian Pop
e741924230 fail to find dimensions when ElementSize is nullptr
when ScalarEvolution::getElementSize returns nullptr it is safe to early return
in ScalarEvolution::findArrayDimensions such that we avoid later problems when
we try to divide the terms by ElementSize.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209837 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-29 19:44:05 +00:00
Sanjay Patel
f558122fe5 test check-in: added missing parenthesis in comment
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209763 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-28 19:03:33 +00:00
Sebastian Pop
5013d1d5e4 avoid type mismatch when building SCEVs
This is a corner case I have stumbled upon when dealing with ARM64 type
conversions. I was not able to extract a testcase for the community codebase to
fail on. The patch conservatively discards a division that would have ended up
in an ICE due to a type mismatch when building a multiply expression. I have
also added code to a place that builds add expressions and in which we should be
careful not to pass in operands of different types.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209694 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-27 22:42:00 +00:00
Sebastian Pop
bf48d8ae51 do not use the GCD to compute the delinearization strides
We do not need to compute the GCD anymore after we removed the constant
coefficients from the terms: the terms are now all parametric expressions and
there is no need to recognize constant terms that divide only a subset of the
terms. We only rely on the size of the terms, i.e., the number of operands in
the multiply expressions, to sort the terms and recognize the parametric
dimensions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209693 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-27 22:41:56 +00:00
Sebastian Pop
79facc9e29 remove BasePointer before delinearizing
No functional change is intended: instead of relying on the delinearization to
come up with the base pointer as a remainder of the divisions in the
delinearization, we just compute it from the array access and use that value.
We substract the base pointer from the SCEV to be delinearized and that
simplifies the work of the delinearizer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209692 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-27 22:41:51 +00:00
Sebastian Pop
421b2c571c remove constant terms
The delinearization is needed only to remove the non linearity induced by
expressions involving multiplications of parameters and induction variables.
There is no problem in dealing with constant times parameters, or constant times
an induction variable.

For this reason, the current patch discards all constant terms and multipliers
before running the delinearization algorithm on the terms. The only thing
remaining in the term expressions are parameters and multiply expressions of
parameters: these simplified term expressions are passed to the array shape
recognizer that will not recognize constant dimensions anymore: these will be
recognized as different strides in parametric subscripts.

The only important special case of a constant dimension is the size of elements.
Instead of relying on the delinearization to infer the size of an element,
compute the element size from the base address type. This is a much more precise
way of computing the element size than before, as we would have mixed together
the size of an element with the strides of the innermost dimension.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209691 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-27 22:41:45 +00:00
Michael Zolotukhin
90e79a50bb Some cleanup for r209568.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209634 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-26 14:49:46 +00:00
Michael Zolotukhin
45788be6e2 Implement sext(C1 + C2*X) --> sext(C1) + sext(C2*X) and
sext{C1,+,C2} --> sext(C1) + sext{0,+,C2} transformation in Scalar
Evolution.

That helps SLP-vectorizer to recognize consecutive loads/stores.

<rdar://problem/14860614>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209568 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-24 08:09:57 +00:00
Andrew Trick
ab0d042a74 Fix and improve SCEV ComputeBackedgeTankCount.
This is a follow-up to r209358: PR19799: Indvars miscompile due to an
incorrect max backedge taken count from SCEV.

That fix was incomplete as pointed out by Arnold and Michael Z. The
code was also too confusing. It needed a careful rewrite with more
unit tests. This version will also happen to optimize more cases.

<rdar://17005101> PR19799: Indvars miscompile...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209545 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-23 19:47:13 +00:00
Justin Bogner
e318ce611f ScalarEvolution: Fix handling of AddRecs in isKnownPredicate
ScalarEvolution::isKnownPredicate() can wrongly reduce a comparison
when both the LHS and RHS are SCEVAddRecExprs. This checks that both
LHS and RHS are guarded in the case when both are SCEVAddRecExprs.

The test case is against indvars because I could not find a way to
directly test SCEV.

Patch by Sanjay Patel!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209487 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-23 00:06:56 +00:00
Andrew Trick
facca6e3f3 Fix a bug in SCEV's backedge taken count computation from my prior fix in Jan.
This has to do with the trip count computation for loops with multiple
exits, which is quite subtle. Most passes just ask for a single trip
count number, so we must be conservative assuming any exit could be
taken.  Normally, we rely on the "exact" trip count, which was
correctly given as "unknown". However, SCEV also gives a "max"
back-edge taken count. The loops max BE taken count is conservatively
a maximum over the max of each exit's non-exiting iterations
count. Note that some exit tests can be skipped so the max loop
back-edge taken count can actually exceed the max non-exiting
iterations for some exits. However, when we know the loop *latch*
cannot be skipped, we can directly use its max taken count
disregarding other exits. I previously took the minimum here without
checking whether the other exit could be skipped. The correct, and
simpler thing to do here is just to directly use the loop latch's max
non-exiting iterations as the loops max back-edge count.

In the problematic test case, the first loop exit had a max of zero
non-exiting iterations, but could be skipped. The loop latch was known
not to be skipped but had max of one non-exiting iteration. We
incorrectly claimed the loop back-edge could be taken zero times, when
it is actually taken one time.

Fixes Loop %for.body.i: <multiple exits> Unpredictable backedge-taken count.
Loop %for.body.i: max backedge-taken count is 1.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209358 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-22 00:37:03 +00:00
Eric Christopher
68c7a1cb98 Clean up language and grammar.
Based on a patch by jfcaron3@gmail.com!
PR19806

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209216 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-20 17:11:11 +00:00
Nick Lewycky
4bf804fe0d Teach isKnownNonNull that a nonnull return is not null. Add a test for this case as well as the case of a nonnull attribute (already handled but not tested).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209193 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-20 05:13:21 +00:00
Nick Lewycky
fe47ebfad3 Add 'nonnull', a new parameter and return attribute which indicates that the pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209185 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-20 01:23:40 +00:00
Peter Collingbourne
20a6a27bea Check the alwaysinline attribute on the call as well as on the caller.
Differential Revision: http://reviews.llvm.org/D3815

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209150 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-19 18:25:54 +00:00
David Majnemer
3258443195 InstSimplify: Improve handling of ashr/lshr
Summary:
Analyze the range of values produced by ashr/lshr cst, %V when it is
being used in an icmp.

Reviewers: nicholas

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D3774

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209000 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-16 17:14:03 +00:00
David Majnemer
7a2ed26563 InstSimplify: Optimize using dividend in sdiv
Summary:
The dividend in an sdiv tells us the largest and smallest possible
results.  Use this fact to optimize comparisons against an sdiv with a
constant dividend.

Reviewers: nicholas

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D3795

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208999 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-16 16:57:04 +00:00
Juergen Ributzka
9bc1b73c9e Add C API for thread yielding callback.
Sometimes a LLVM compilation may take more time then a client would like to
wait for. The problem is that it is not possible to safely suspend the LLVM
thread from the outside. When the timing is bad it might be possible that the
LLVM thread holds a global mutex and this would block any progress in any other
thread.

This commit adds a new yield callback function that can be registered with a
context. LLVM will try to yield by calling this callback function, but there is
no guaranteed frequency. LLVM will only do so if it can guarantee that
suspending the thread won't block any forward progress in other LLVM contexts
in the same process.

Once the client receives the call back it can suspend the thread safely and
resume it at another time.

Related to <rdar://problem/16728690>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208945 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-16 02:33:15 +00:00
Jay Foad
b7ba5c2e2e Instead of littering asserts throughout the code after every call to
computeKnownBits, consolidate them into one assert at the end of
computeKnownBits itself.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208876 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-15 12:12:55 +00:00
Chandler Carruth
ca323cf916 Teach the constant folder to look through bitcast constant expressions
much more effectively when trying to constant fold a load of a constant.
Previously, we only handled bitcasts by trying to find a totally generic
byte representation of the constant and use that. Now, we look through
the bitcast to see what constant we might fold the load into, and then
try to form a constant expression cast of the found value that would be
equivalent to loading the value.

You might wonder why on earth this actually matters. Well, turns out
that the Itanium ABI causes us to create a single array for a vtable
where the first elements are virtual base offsets, followed by the
virtual function pointers. Because the array is homogenous the element
type is consistently i8* and we inttoptr the virtual base offsets into
the initial elements.

Then constructors bitcast these pointers to i64 pointers prior to
loading them. Boom, no more constant folding of virtual base offsets.
This is the first fix to LLVM to address the *insane* performance Eric
Niebler discovered with Clang on his range comprehensions[1]. There is
more to come though, this doesn't *really* fix the problem fully.

[1]: http://ericniebler.com/2014/04/27/range-comprehensions/

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208856 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-15 09:56:28 +00:00
Alp Toker
727273b11c Fix typos
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208839 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-15 01:52:21 +00:00
Jay Foad
6b543713a2 Rename ComputeMaskedBits to computeKnownBits. "Masked" has been
inappropriate since it lost its Mask parameter in r154011.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208811 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-14 21:14:37 +00:00
David Majnemer
cd237ed585 InstSimplify: Optimize signed icmp of -(zext V)
Summary:
We know that -(zext V) will always be <= zero, simplify signed icmps
that have these.

Uncovered using http://www.cs.utah.edu/~regehr/souper/

Reviewers: nicholas

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D3754

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208809 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-14 20:16:28 +00:00
Jay Foad
5fa4d1cd1a Update the comments for ComputeMaskedBits, which lost its Mask parameter
in r154011.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208757 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-14 08:00:07 +00:00
Sebastian Pop
d2b27bba87 use nullptr instead of NULL
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208622 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-12 20:11:01 +00:00
Sebastian Pop
2f5f1c2ccb do not assert when delinearization fails
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208615 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-12 19:01:53 +00:00
Sebastian Pop
d9673ebd34 use isZero()
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208614 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-12 19:01:49 +00:00
Benjamin Kramer
bfd5dad4c9 SCEV: Use range-based for loop and fold variable into assert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208476 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-10 17:47:18 +00:00
Sebastian Pop
754e940865 move findArrayDimensions to ScalarEvolution
we do not use the information from SCEVAddRecExpr to compute the shape of the array,
so a better place for this function is in ScalarEvolution.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208456 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-09 22:45:07 +00:00
Sebastian Pop
f255eb9643 fix typo in debug message
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208455 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-09 22:45:02 +00:00
Tobias Grosser
24ac5dfba0 Correct formatting.
Sorry for the commit spam. My clang-format crashed on me and the vim
plugin did not print an error, but instead just left the formatting
untouched.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208358 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-08 21:43:19 +00:00
Tobias Grosser
3a722581b9 Use std::remove_if to remove elements from a vector
Suggested-by: Benjamin Kramer <benny.kra@gmail.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-08 21:32:59 +00:00
Rafael Espindola
2413bf3004 Use a range loop.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208343 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-08 17:57:50 +00:00
Tobias Grosser
f46646d87b Revert "SCEV: Use I = vector<>.erase(I) to iterate and delete at the same time"
as committed in r208282. The original commit was incorrect.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208286 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-08 07:55:34 +00:00
Tobias Grosser
96f8c5651c SCEV: Use I = vector<>.erase(I) to iterate and delete at the same time
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208282 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-08 07:12:44 +00:00
Sebastian Pop
4842e7db63 avoid segfaulting
*Quotient and *Remainder don't have to be initialized.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208238 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-07 19:00:37 +00:00
Sebastian Pop
bde4574fcb do not collect undef terms
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208237 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-07 19:00:32 +00:00
Sebastian Pop
5026b2cc8b split delinearization pass in 3 steps
To compute the dimensions of the array in a unique way, we split the
delinearization analysis in three steps:

- find parametric terms in all memory access functions
- compute the array dimensions from the set of terms
- compute the delinearized access functions for each dimension

The first step is executed on all the memory access functions such that we
gather all the patterns in which an array is accessed. The second step reduces
all this information in a unique description of the sizes of the array. The
third step is delinearizing each memory access function following the common
description of the shape of the array computed in step 2.

This rewrite of the delinearization pass also solves a problem we had with the
previous implementation: because the previous algorithm was by induction on the
structure of the SCEV, it would not correctly recognize the shape of the array
when the memory access was not following the nesting of the loops: for example,
see polly/test/ScopInfo/multidim_only_ivs_3d_reverse.ll

; void foo(long n, long m, long o, double A[n][m][o]) {
;
;   for (long i = 0; i < n; i++)
;     for (long j = 0; j < m; j++)
;       for (long k = 0; k < o; k++)
;         A[i][k][j] = 1.0;

Starting with this patch we no longer delinearize access functions that do not
contain parameters, for example in test/Analysis/DependenceAnalysis/GCD.ll

;;  for (long int i = 0; i < 100; i++)
;;    for (long int j = 0; j < 100; j++) {
;;      A[2*i - 4*j] = i;
;;      *B++ = A[6*i + 8*j];

these accesses will not be delinearized as the upper bound of the loops are
constants, and their access functions do not contain SCEVUnknown parameters.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208232 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-07 18:01:20 +00:00
Tobias Grosser
a1f8bd6753 [C++11] Add NArySCEV->Operands iterator range
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208158 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-07 06:07:47 +00:00
Duncan P. N. Exon Smith
cca77fc0d6 blockfreq: Move include to .cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208035 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-06 01:57:42 +00:00
Chandler Carruth
febf86d7e3 [LCG] Add the last (and most complex) of the edge insertion mutation
operations on the call graph. This one forms a cycle, and while not as
complex as removing an internal edge from an SCC, it involves
a reasonable amount of work to find all of the nodes newly connected in
a cycle.

Also somewhat alarming is the worst case complexity here: it might have
to walk roughly the entire SCC inverse DAG to insert a single edge. This
is carefully documented in the API (I hope).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207935 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-04 09:38:32 +00:00
Juergen Ributzka
b2bd7e89e6 [TBAA] Fix handling of mixed TBAA (path-aware and non-path-aware TBAA).
This fix simply ensures that both metadata nodes are path-aware before
performing path-aware alias analysis.

This issue isn't normally triggered in LLVM, because we perform an autoupgrade
of the TBAA metadata to the new format when reading in LL or BC files. This
issue only appears when a client creates the IR manually and mixes old and new
TBAA metadata format.

This fixes <rdar://problem/16760860>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207923 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-03 22:32:52 +00:00
Chandler Carruth
3ce8291da3 [LCG] Add the other simple edge insertion API to the call graph. This
just connects an SCC to one of its descendants directly. Not much of an
impact. The last one is the hard one -- connecting an SCC to one of its
ancestors, and thereby forming a cycle such that we have to merge all
the SCCs participating in the cycle.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207751 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-01 12:18:20 +00:00