- One formatting change.

No intended functionality change.

llvm-svn: 77717

llvm-svn: 77685

llvm-svn: 77635

llvm-svn: 77605

a Twine, e.g., for names).
 - I am a little ambivalent about this; we don't want the string conversion of
   utostr, but using overload '+' mixed with string and integer arguments is
   sketchy. On the other hand, this particular usage is something of an idiom.

llvm-svn: 77579

llvm-svn: 77519

llvm-svn: 77516

llvm-svn: 77494

llvm-svn: 77347

llvm-svn: 77266

llvm-svn: 77152

 - Some clients which used DOUT have moved to DEBUG. We are deprecating the
   "magic" DOUT behavior which avoided calling printing functions when the
   statement was disabled. In addition to being unnecessary magic, it had the
   downside of leaving code in -Asserts builds, and of hiding potentially
   unnecessary computations.

llvm-svn: 77019

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

llvm-svn: 77011

instead of getAnalysis<TargetData>().

llvm-svn: 76982

llvm-svn: 76962

llvm-svn: 76782

llvm-svn: 76702

llvm-svn: 76598

llvm-svn: 76595

doesn't cause ".no_dead_strip" to be emitted on darwin.

llvm-svn: 76399

"private" symbols which the assember shouldn't strip, but which the linker may
remove after evaluation. This is mostly useful for Objective-C metadata.

This is plumbing, so we don't have a use of it yet. More to come, etc.

llvm-svn: 76385

llvm-svn: 76284

our current context-passing stuff, which is also fixed here

llvm-svn: 76089

llvm-svn: 75863

llvm-svn: 75703

This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").

llvm-svn: 75640

llvm-svn: 75497

Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.

llvm-svn: 75379

This started as a small change, I swear.  Unfortunately, lots of things call the [I|F]CmpInst constructors.  Who knew!?

llvm-svn: 75200

llvm-svn: 75025

llvm-svn: 74985

llvm-svn: 74878

Finish LLVMContext-ing lib/Analysis.  This required pushing LLVMContext's through the ValueTracking API.

llvm-svn: 74873

llvm-svn: 74844

llvm-svn: 74811

llvm-svn: 74773

to not have to create a temporary vector (in the API at least).  Patch by Jay Foad!

llvm-svn: 74584

Remove debug info anchors - llvm.dbg.compile_units, llvm.dbg.subprograms
and llvm.dbg.global_variables.

llvm-svn: 74251

>> What if my global variable was into a different address space than stack?
>>     
>
> It doesn't matter in terms of semantics: because AnalyzeGlobal
> returned false, we're guaranteed the address of the global is never
> taken.  I wouldn't be surprised if we end up generating invalid IR in
> some cases, though, because of the semantics of replaceAllUsesWith.
> Do you have a testcase that breaks?
>
>   
The problem is replaceAllUsesWith asserts for type mismatch here. Try attached .bc with llvm-ld.

assert(New->getType() == getType() &&
        "replaceAllUses of value with new value of different type!");

Since stack is always on address space zero, I don't think that type of GV in a different address space is ever going to match.
The other way is to allow replaceAllUsesWith to ignore address spaces while comparing types. (do we have  a way to do that ?).
But then such an optimization may fail the entire idea of user wanting to place a variable into different memory space. The original idea of user might be to save on the stack space (data memory) and hence he asked the variable to be placed into different memory space (program memory). So the best bet here is to deny this optimization by checking

GV->getType()->getAddressSpace() == 0. 

llvm-svn: 73605

llvm-svn: 73412