- Update register allocation hint after coalescing. This is done by the target since the hint is target dependent. This is important for ARM register pair hints.
- Register allocator should resolve the second part of the hint (register number) before passing it to the target since it knows virtual register to physical register mapping.
- More fixes to get ARM load / store double word working.

llvm-svn: 73671

adding a check to catch this case at compile time
instead of quietly generating incorrect code.
That will at least let us identify CBE failures
that are not due to this problem.

llvm-svn: 73668

llvm-svn: 73666

llvm-svn: 73665

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

llvm-svn: 73662

llvm-svn: 73661

Emit switch directive for it. I have no idea whether this is
requirement for Darwin or not.

llvm-svn: 73660

multiple users.

llvm-svn: 73656

llvm-svn: 73653

llvm-svn: 73647

llvm-svn: 73646

llvm-svn: 73643

llvm-svn: 73642

llvm-svn: 73639

We need to use double-checked locking for lazy initialization in this case when running multithreaded.

llvm-svn: 73636

llvm-svn: 73635

llvm-svn: 73634

llvm-svn: 73633

move loads back past a check that the load address
is valid, see new testcase.  The test that went
in with 72661 has exactly this case, except that
the conditional it's moving past is checking
something else; I've settled for changing that
test to reference a global, not a pointer.  It
may be possible to scan all the tests you pass and
make sure none of them are checking any component
of the address, but it's not trivial and I'm not
trying to do that here.

llvm-svn: 73632

llvm-svn: 73631

Add an RAII ScopedWriter, which allows one to acquire a writer lock for the duration of a scope.  Simplify a lot of uses of
writer locks in Constants.cpp by using it.

llvm-svn: 73630

Simplify the locking on the Constants tables, and make it more efficient, by pushing it into the ValueMap from the callers.
Document those ValueMap functions that are _not_ locked, so that callers are aware that they need to do the locking themselves.

llvm-svn: 73628

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

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

llvm-svn: 73622

llvm-svn: 73621

llvm-svn: 73620

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

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