from the host and hope that works.

llvm-svn: 80751

llvm-svn: 80519

llvm-svn: 80518

llvm-svn: 80363

make check in a non-clean directory causes it to fail (for example when running
make check twice), since execution counts will differ.

llvm-svn: 80362

error.

llvm-svn: 80357

llvm-svn: 80356

llvm-svn: 80355

tests can test only parts of this system.

llvm-svn: 80348

This is a simple AliasAnalysis implementation which works by making
ScalarEvolution queries. ScalarEvolution has a more complete understanding
of arithmetic than BasicAA's collection of ad-hoc checks, so it handles
some cases that BasicAA misses, for example p[i] and p[i+1] within the
same iteration of a loop.

This is currently experimental. It may be that the main use for this pass
will be to help find cases where BasicAA can be profitably extended, or
to help in the development of the overall AliasAnalysis infrastructure,
however it's also possible that it could grow up to become a directly
useful pass.

llvm-svn: 80098

llvm-svn: 79633

llvm-svn: 79615

depend on TargetData information.

llvm-svn: 79491

using formatted_raw_ostream's PadToColumn.

Before:

bb1:            ; preds = %bb
  %2 = sext i32 %i.01 to i64            ; <i64> [#uses=1]
  %3 = getelementptr double* %p, i64 %2         ; <double*> [#uses=1]
  %4 = load double* %3, align 8         ; <double> [#uses=1]
  %5 = fmul double %4, 1.100000e+00             ; <double> [#uses=1]
  %6 = sext i32 %i.01 to i64            ; <i64> [#uses=1]
  %7 = getelementptr double* %p, i64 %6         ; <double*> [#uses=1]

After:

bb1:                                        ; preds = %bb
  %2 = sext i32 %i.01 to i64                ; <i64> [#uses=1]
  %3 = getelementptr double* %p, i64 %2     ; <double*> [#uses=1]
  %4 = load double* %3, align 8             ; <double> [#uses=1]
  %5 = fmul double %4, 1.100000e+00         ; <double> [#uses=1]
  %6 = sext i32 %i.01 to i64                ; <i64> [#uses=1]
  %7 = getelementptr double* %p, i64 %6     ; <double*> [#uses=1]

Several tests required whitespace adjustments.

llvm-svn: 78816

llvm-svn: 78446

llvm-svn: 78384

llvm-svn: 78157

llvm-svn: 78153

llvm-svn: 77926

llvm-svn: 77398

after their associated opcodes rather than before. This makes them
a little easier to read.

llvm-svn: 77194

the step value as unsigned, the start value and the addrec
itself still need to be treated as signed.

llvm-svn: 77078

analyzing add recurrences.

llvm-svn: 77034

llvm-svn: 76880

(x pred y) with more thorough code that does more complete canonicalization
before resorting to range checks. This helps it find more cases where
the canonicalized expressions match.

llvm-svn: 76671

llvm-svn: 76526

For now this only computes the allocated size of the memory pointed to by a
pointer, and offset a pointer from allocated pointer.
The actual checkLimits part will come later, after another round of review.

llvm-svn: 75657

llvm-svn: 75533

than a wider one, before trying to compare their contents which will crash
if their sizes are different.

llvm-svn: 74792

llvm-svn: 74499

llvm-svn: 74402

llvm-svn: 74049

sides is CouldNotCompute, the resulting exact count must be CouldNotCompute.

llvm-svn: 73920

conservatively correctly, instead of aborting.

llvm-svn: 73908

blocks, and also exit blocks with multiple conditions (combined
with (bitwise) ands and ors). It's often infeasible to compute an
exact trip count in such cases, but a useful upper bound can often
be found.

llvm-svn: 73866

overflow when computing a integer division to round up.

Thanks to Nick Lewycky for noticing this!

llvm-svn: 73862

If C is a single bit and the and gets analyzed as a truncate and
zero-extend, the xor can be represnted as an add.

llvm-svn: 73664

llvm-svn: 73633

that gets recognized with a SCEVZeroExtendExpr must be an And
with a low-bits mask. With r73540, this is no longer the case.

llvm-svn: 73594

integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.

For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.

This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt

llvm-svn: 72897