|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| | We may need to change the way profile counter values are stored, but
saturation is the wrong thing to do.  Just remove it for now.
Patch by Alastair Murray!
llvm-svn: 166938 | 
| | 
| 
| 
| 
| 
| | noise and blocks finding more severe bugs.
llvm-svn: 166873 | 
| | 
| 
| 
| 
| 
| | way it handles strings.
llvm-svn: 166872 | 
| | 
| 
| 
| 
| 
| 
| | It was unmaintained and not much more than a stub. The new DependenceAnalysis
pass is both more general and complete.
llvm-svn: 166810 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Enabled with -verify-scev. This could be extended significantly but hopefully
catches the common cases now. Note that it's not enabled by default in any
configuration because the way it tries to distinguish SCEVs is still fragile and
may produce false positives. Also the test-suite isn't clean yet, one example
is that it fails if a pass drops an NSW bit but it's still present in SCEV's
cached. Cleaning up all those cases will take some time.
llvm-svn: 166786 | 
| | 
| 
| 
| 
| 
| | PR14183.
llvm-svn: 166785 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | instructions in a block. GetUnderlyingObject is more expensive than it looks as
it can, for instance, call SimplifyInstruction.
This might have some behavioural changes in odd corner cases, but only because
of some strange artefacts of the original implementation. If you were relying
on those, we can fix that by replacing this with a smarter algorithm. Change
passes the existing tests.
llvm-svn: 166754 | 
| | 
| 
| 
| | llvm-svn: 166739 | 
| | 
| 
| 
| | llvm-svn: 166726 | 
| | 
| 
| 
| | llvm-svn: 166688 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | When the trip count is -1, getSmallConstantTripMultiple could return zero,
and this would cause runtime loop unrolling to assert. Instead of returning
zero, one is now returned (consistent with the existing overflow cases).
Fixes PR14167.
llvm-svn: 166612 | 
| | 
| 
| 
| | llvm-svn: 166607 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | address space.
This checkin also adds in some tests that utilize these paths and updates some of the
clients.
llvm-svn: 166578 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | loads. It's not really profitable and may result in GVN going into an infinite
loop when it hits constructs like this:
     %x = gep %some.type %x, ...
Found via an LTO build of LLVM.
llvm-svn: 166490 | 
| | 
| 
| 
| | llvm-svn: 166340 | 
| | 
| 
| 
| 
| 
| | Just constant fold them so they can't cause any trouble. Fixes PR12627.
llvm-svn: 166286 | 
| | 
| 
| 
| 
| 
| | interface.
llvm-svn: 166264 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The TargetTransform changes are breaking LTO bootstraps of clang.  I am
working with Nadav to figure out the problem, but I am reverting it for now
to get our buildbots working.
This reverts svn commits: 165665 165669 165670 165786 165787 165997
and I have also reverted clang svn 165741
llvm-svn: 166168 | 
| | 
| 
| 
| 
| 
| | different pointer sizes on a per address space basis.
llvm-svn: 165941 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | DependenceAnalysis.cpp:1164:32: warning: implicit truncation from 'int' to bitfield changes value from -5 to 3
      [-Wconstant-conversion]
    Result.DV[Level].Direction &= ~Dependence::DVEntry::GT;
                               ^  ~~~~~~~~~~~~~~~~~~~~~~~~
Patch from Preston Briggs <preston.briggs@gmail.com>.
llvm-svn: 165784 | 
| | 
| 
| 
| | llvm-svn: 165747 | 
| | 
| 
| 
| 
| 
| | per address space pointer sizes to be optimized correctly.
llvm-svn: 165726 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Patch from Preston Briggs <preston.briggs@gmail.com>.
This is an updated version of the dependence-analysis patch, including an MIV
test based on Banerjee's inequalities.
It's a fairly complete implementation of the paper
    Practical Dependence Testing
    Gina Goff, Ken Kennedy, and Chau-Wen Tseng
    PLDI 1991
It cannot yet propagate constraints between coupled RDIV subscripts (discussed
in Section 5.3.2 of the paper).
It's organized as a FunctionPass with a single entry point that supports testing
for dependence between two instructions in a function. If there's no dependence,
it returns null. If there's a dependence, it returns a pointer to a Dependence
which can be queried about details (what kind of dependence, is it loop
independent, direction and distance vector entries, etc). I haven't included
every imaginable feature, but there's a good selection that should be adequate
for supporting many loop transformations. Of course, it can be extended as
necessary.
Included in the patch file are many test cases, commented with C code showing
the loops and array references.
llvm-svn: 165708 | 
| | 
| 
| 
| 
| 
| | information.
llvm-svn: 165665 | 
| | 
| 
| 
| | llvm-svn: 165551 | 
| | 
| 
| 
| | llvm-svn: 165550 | 
| | 
| 
| 
| 
| 
| 
| | We use the enums to query whether an Attributes object has that attribute. The
opaque layer is responsible for knowing where that specific attribute is stored.
llvm-svn: 165488 | 
| | 
| 
| 
| 
| 
| 
| 
| | methods for them.
No functionality change intended.
llvm-svn: 165466 | 
| | 
| 
| 
| 
| 
| | the same thing. No functionality change.
llvm-svn: 165435 | 
| | 
| 
| 
| | llvm-svn: 165402 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Without this change, when the estimated cost for inlining a function with
an "alwaysinline" attribute was lower than the inlining threshold, the
getInlineCost function was returning that estimated cost rather than the
special InlineCost::AlwaysInlineCost value. That is fine in the normal
inlining case, but it can fail when the inliner considers the opportunity
cost of inlining into an internal or linkonce-odr function. It may decide
not to inline the always-inline function in that case. The fix here is just
to make getInlineCost always return the special value for always-inline
functions. I ran into this building clang with libc++. Tablegen failed to
link because of an always-inline function that was not inlined. I have been
unable to reduce the testcase down to a reasonable size.
llvm-svn: 165367 | 
| | 
| 
| 
| 
| 
| | alignment of the return type.  Teach the optimizers this.
llvm-svn: 165226 | 
| | 
| 
| 
| | llvm-svn: 165211 | 
| | 
| 
| 
| 
| 
| 
| | source of false positives due to globals being declared in a header with some
kind of incomplete (small) type, but the actual definition being bigger.
llvm-svn: 164912 | 
| | 
| 
| 
| 
| 
| | See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767
llvm-svn: 164768 | 
| | 
| 
| 
| | llvm-svn: 164767 | 
| | 
| 
| 
| 
| 
| 
| | The hasFnAttr method has been replaced by querying the Attributes explicitly. No
intended functionality change.
llvm-svn: 164725 | 
| | 
| 
| 
| 
| 
| 
| | teach the callgraph logic to not create callgraph edges to intrinsics for invoke
instructions; it already skips this for call instructions.  Fixes PR13903.
llvm-svn: 164707 | 
| | 
| 
| 
| | llvm-svn: 164671 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Previously it was only be able to detect problems if the pointer was a numerical
value (eg inttoptr i32 1 to i32*), but not if it was an alloca or globa.  The
reason was the use of ComputeMaskedBits: imagine you have "alloca i8, align 2",
and ask ComputeMaskedBits what it knows about the bits of the alloca pointer.
It can tell you that the bottom bit is known zero (due to align 2) but it can't
tell you that bit 1 is known one.  That's because the address could be an even
multiple of 2 rather than an odd multiple, eg it might be a multiple of 4.  Thus
trying to use KnownOne is ineffective in the case of an alloca as it will never
have any bits set.  Instead look explicitly for constant offsets from allocas
and globals.
llvm-svn: 164595 | 
| | 
| 
| 
| 
| 
| 
| | ArePhisAssumedNoAlias, and warns that OrigAliasResult may be used uninitialized.
Pacify GCC.
llvm-svn: 164229 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | caller.
Example:
void foo() {
 ... foo();   // I'm recursive!
  bar();
}
bar() {  int a[1000];  // large stack size }
rdar://10853263
llvm-svn: 164207 | 
| | 
| 
| 
| 
| 
| 
| 
| | "#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)"
No functional change. Update r163344.
llvm-svn: 163679 | 
| | 
| 
| 
| 
| 
| | No functional change.
llvm-svn: 163344 | 
| | 
| 
| 
| | llvm-svn: 163324 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Enhances basic alias analysis to recognize phis whose first incoming values are
NoAlias and whose other incoming values are just the phi node itself through
some amount of recursion.
Example: With this change basicaa reports that ptr_phi and ptr_phi2 do not alias
each other.
bb:
 ptr = ptr2 + 1
loop:
  ptr_phi = phi [bb, ptr], [loop, ptr_plus_one]
  ptr2_phi = phi [bb, ptr2], [loop, ptr2_plus_one]
  ...
  ptr_plus_one = gep ptr_phi, 1
  ptr2_plus_one = gep ptr2_phi, 1
This enables the elimination of one load in code like the following:
extern int foo;
int test_noalias(int *ptr, int num, int* coeff) {
  int *ptr2 = ptr;
  int result = (*ptr++) * (*coeff--);
  while (num--) {
    *ptr2++ = *ptr;
    result +=  (*coeff--) * (*ptr++);
  }
  *ptr = foo;
  return result;
}
Part 2/2 of fix for PR13564.
llvm-svn: 163319 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | If we can show that the base pointers of two GEPs don't alias each other using
precise analysis and the indices and base offset are equal then the two GEPs
also don't alias each other.
This is primarily needed for the follow up patch that analyses NoAlias'ing PHI
nodes.
Part 1/2 of fix for PR13564.
llvm-svn: 163317 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | switch, make sure we include the value for the cases when calculating edge
value from switch to the default destination.
rdar://12241132
llvm-svn: 163270 | 
| | 
| 
| 
| | llvm-svn: 163258 | 
| | 
| 
| 
| 
| 
| 
| 
| | It relies on clear() being fast and the cache rarely has more than 1 or 2
elements, so give it an inline capacity and always shrink it back down in case
it grows. DenseMap will grow to 64 buckets which makes clear() a lot slower.
llvm-svn: 163215 |