llvm-svn: 73625

Type safety for Constants.cpp!  Some of this is temporary, as I'm planning to push some of the R/W locking into FoldingSet.

llvm-svn: 73624

Make sure that .td and .def files get into the list of headers in a CMake build, for use in Xcode and Visual Studio

llvm-svn: 73623

Patch by Viktor Kutuzov and Anton Korzh from Access Softek, Inc.

llvm-svn: 73622

llvm-svn: 73621

llvm-svn: 73620

llvm-svn: 73619

llvm-svn: 73618

We need to guard reads of the AbstractTypeUsers list, as well as writes to it.  While it would be nice to use a R/W lock here,
we can't, because it HAS to be recursive.

llvm-svn: 73617

llvm-svn: 73616

llvm-svn: 73615

llvm-svn: 73614

llvm-svn: 73613

llvm-svn: 73612

llvm-svn: 73611

of targets for various purposes.

llvm-svn: 73610

llvm-svn: 73609

lock.  This is obviously bad, but at least it's threadsafe!  If you know how
to improve this in a pre-Vista friendly well, patches welcome!

Patch by Max Burke.

llvm-svn: 73607

printers.

While I'm here, alphabetize.

llvm-svn: 73606

>> 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: 73604

llvm-svn: 73603

llvm-svn: 73602

llvm-svn: 73601

llvm-svn: 73600

creating new files very well).

llvm-svn: 73599

SRem.

llvm-svn: 73598

llvm-svn: 73597

llvm-svn: 73596

target so that the JIT works in LLI, not just the interpreter.

llvm-svn: 73595

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

Do not use first actual instruction's location for prologue. The debug wants to skip prologue while setting a breakpoint for the function.

llvm-svn: 73592

llvm-svn: 73591

Define LLVM_NATIVE_ARCH in llvm/Config/config.h to be the LLVM back end that corresponds to the native executable, but only when that LLVM back end is being built

llvm-svn: 73590

llvm-svn: 73589

llvm-svn: 73588

thread-safe reference counting.

llvm-svn: 73587

llvm-svn: 73586

llvm-svn: 73585

llvm-svn: 73584