lowering code and update testcases.

llvm-svn: 91979

llvm-svn: 91875

miscompile (i386.o miscompares) but it happens both with and without
this patch.

llvm-svn: 91532

Will reapply with a fix when I get a chance.

llvm-svn: 91486

llvm-svn: 91438

llvm-svn: 91428

llvm-svn: 90297

object size intrinsic and verify return type is correct. Collect various
code in one place.

llvm-svn: 89523

llvm-svn: 89482

llvm-svn: 89479

a name.

llvm-svn: 88908

putchar in case there is an error.

llvm-svn: 86515

llvm-svn: 86141

do anything than return "I don't know" at the moment.

llvm-svn: 85189

llvm-svn: 83489

where the element is of a basic builtin type.  For example, to get
an i8* use getInt8PtrTy.

llvm-svn: 83379

the new predicates I added) instead of going through a context and doing a
pointer comparison.  Besides being cheaper, this allows a smart compiler
to turn the if sequence into a switch.

llvm-svn: 83297

calls, since direct calls don't always reflect the attributes of their
callees.

llvm-svn: 82867

llvm-svn: 82823

typically faster then doing a general pow.

llvm-svn: 82819

Reviewed by Dan Gohman.

llvm-svn: 82300

simplifylibcalls optimization is thus valid for C++ but not C.
It's not important enough to worry about for C++ apps, so just
remove it.

rdar://7191924

llvm-svn: 80887

llvm-svn: 80766

before performing optimizations based on constant string values.

llvm-svn: 79384

llvm-svn: 79298

llvm-svn: 78948

metadata related, which I'm waiting on to avoid conflicting with Devang.

llvm-svn: 77721

llvm-svn: 77516

 - Call RAUW to delete all instructions (this is a patch from Nick Lewycky).

llvm-svn: 77512

llvm-svn: 77494

into a new BB that has no predecessors.

llvm-svn: 77433

llvm-svn: 77347

llvm-svn: 77247

llvm-svn: 77148

llvm-svn: 77145

Also, change MDString to use a StringRef.

llvm-svn: 77098

Revert the ConstantInt constructors back to their 2.5 forms where possible, thanks to contexts-on-types.  More to come.

llvm-svn: 77011

 - Yay for '-'s and simplifications!

 - I kept StringMap::GetOrCreateValue for compatibility purposes, this can
   eventually go away. Likewise the StringMapEntry Create functions still follow
   the old style.

 - NIFC.

llvm-svn: 76888

llvm-svn: 76702

where int is 32 bits.

llvm-svn: 76293