| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.
Ironically, the unittest is already in the right library.
llvm-svn: 202824
|
|
|
|
|
|
|
|
|
|
|
| |
Move the test for this class into the IR unittests as well.
This uncovers that ValueMap too is in the IR library. Ironically, the
unittest for ValueMap is useless in the Support library (honestly, so
was the ValueHandle test) and so it already lives in the IR unittests.
Mmmm, tasty layering.
llvm-svn: 202821
|
|
|
|
|
|
| |
obviously is coupled to the IR.
llvm-svn: 202818
|
|
|
|
|
|
|
| |
abstracting between a CallInst and an InvokeInst, both of which are IR
concepts.
llvm-svn: 202816
|
|
|
|
|
|
|
|
|
| |
name might indicate, it is an iterator over the types in an instruction
in the IR.... You see where this is going.
Another step of modularizing the support library.
llvm-svn: 202815
|
|
|
|
|
|
| |
Remove the old functions.
llvm-svn: 202636
|
|
|
|
| |
llvm-svn: 202596
|
|
|
|
|
|
|
|
|
| |
The API expects an ISD opcode, not an IR opcode.
Fixes a regression for R600.
Related to <rdar://problem/15519855>.
llvm-svn: 201923
|
|
CodeGenPrepare uses extensively TargetLowering which is part of libLLVMCodeGen.
This is a layer violation which would introduce eventually a dependence on
CodeGen in ScalarOpts.
Move CodeGenPrepare into libLLVMCodeGen to avoid that.
Follow-up of <rdar://problem/15519855>
llvm-svn: 201912
|