llvm-svn: 44531

llvm-svn: 44528

llvm-svn: 44517

into alias analysis.  This meant updating the API
which now has versions of the getModRefBehavior,
doesNotAccessMemory and onlyReadsMemory methods
which take a callsite parameter.  These should be
used unless the callsite is not known, since in
general they can do a better job than the versions
that take a function.  Also, users should no longer
call the version of getModRefBehavior that takes
both a function and a callsite.  To reduce the
chance of misuse it is now protected.

llvm-svn: 44487

llvm-svn: 44482

llvm-svn: 44479

information matching did not exactly match the underlying stream's scoping
information.

llvm-svn: 44470

llvm-svn: 44467

llvm-svn: 44460

llvm-svn: 44458

attributes.  While there, I noticed that not all
attribute methods returned a pointer-to-constant,
so I fixed that.

llvm-svn: 44457

function parameters.

llvm-svn: 44452

llvm-svn: 44446

llvm-svn: 44443

llvm-svn: 44437

in the middle of a split basic block, create a new live interval starting at
the def. This avoid artifically extending the live interval over a number of
cycles where it is dead. e.g.

bb1:
       = vr1204   (use / kill) <= new interval starts and ends here.
...
...
vr1204 =          (new def)   <= start a new interval here.
       = vr1204   (use)

llvm-svn: 44436

llvm-svn: 44434

llvm-svn: 44433

llvm-svn: 44428

llvm-svn: 44427

  unsigned char *llvm_cbe_X;
...
  llvm_cbe_X = 0; *((void**)&llvm_cbe_X) = __builtin_stack_save();

instead of:

  llvm_cbe_X = __builtin_stack_save();

See PR1809 for details.

llvm-svn: 44415

CodeGen/Generic/fp_to_int.ll among others.  Its unclear why this 
just started failing...

llvm-svn: 44407

llvm-svn: 44406

use them.

llvm-svn: 44403

in this call:

	Result.IntVal = APInt(80, 2, x);

What is x?

	uint16_t x[8];

I deduce that the APInt constructor being used is this one:

  APInt(uint32_t numBits, uint64_t val, bool isSigned = false);

rather than this one:

  APInt(uint32_t numBits, uint32_t numWords, const uint64_t bigVal[]);

That doesn't seem right!  This fix compiles but is otherwise completely
untested.

llvm-svn: 44400

llvm-svn: 44399

llvm-svn: 44386

llvm-svn: 44384

llvm-svn: 44382

llvm-svn: 44380

llvm-svn: 44378

llvm-svn: 44374

with not being able to find printf.

llvm-svn: 44373

llvm-svn: 44371

llvm-svn: 44370

introduced by this patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071126/055824.html

llvm-svn: 44364

the function type, instead they belong to functions
and function calls.  This is an updated and slightly
corrected version of Reid Spencer's original patch.
The only known problem is that auto-upgrading of
bitcode files doesn't seem to work properly (see
test/Bitcode/AutoUpgradeIntrinsics.ll).  Hopefully
a bitcode guru (who might that be? :) ) will fix it.

llvm-svn: 44359

llvm-svn: 44352

llvm-svn: 44351

Make LoopInfoBase more generic, in preparation for having MachineLoopInfo.  This involves a small interface change.

llvm-svn: 44348