patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
delete the MDNode that changed, rather than the other MDNode.
This is less work, because it doesn't require the changed node
to be re-inserted into the uniquing map and it doesn't require
the is-function-local flag to be recomputed. Also, it avoids
trouble when the existing node is part of a complicated
data structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114996 91177308-0d34-0410-b5e6-96231b3b80d8
non-function-local value, it may result in the metadata no longer needing to be
function-local. Check for this condition, and clear the isFunctionLocal flag, if
it's still in the uniquing map, since any node in the uniquing map needs to have
an accurate function-local flag.
Also, add an assert to help catch problematic cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113828 91177308-0d34-0410-b5e6-96231b3b80d8
for MDNodes, since this information is effectively implied by
the operands. This allow allows the code to avoid doing a
recursive is-it-really-function-local check in some cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111995 91177308-0d34-0410-b5e6-96231b3b80d8
not part of the IR, are not uniqued, and may be safely RAUW'd.
This replaces a variety of alternate mechanisms for achieving
the same effect.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111681 91177308-0d34-0410-b5e6-96231b3b80d8
Make MDNode::destroy private.
Fix the one thing that used MDNode::destroy, outside of MDNode itself.
One should never delete or destroy an MDNode explicitly. MDNodes
implicitly go away when there are no references to them (implementation
details aside).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109028 91177308-0d34-0410-b5e6-96231b3b80d8
buildbot: the debugging and non-debugging versions of getFunction were not
functionally equivalent: the non-debugging version wrongly assumed that if a
metadata operand was not metadata, then it had a non-null containing function.
This is not true, since the operand might be a global value, constant etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103008 91177308-0d34-0410-b5e6-96231b3b80d8
RAUW of a global variable with a local variable in function F,
if function local metadata M in function G was using the global
then M would become function-local to both F and G, which is not
allowed. See the testcase for an example. Fixed by detecting
this situation and zapping the metadata operand when it occurs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103007 91177308-0d34-0410-b5e6-96231b3b80d8
being a TrackingVH<MDNode> to a NewDebugLoc, shrinking
sizeof(Instruction) a lot, and providing clients the ability
to deal with locations in terms of NewDebugLoc instead of
having to deal with Metadata. This is still fully compatible
with all clients that *do* use MDNodes for everything of
course.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100088 91177308-0d34-0410-b5e6-96231b3b80d8
instructions. In addition to being a convenience,
they are faster than the old apis, particularly when
not going from an MDKindID like people should be
doing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99982 91177308-0d34-0410-b5e6-96231b3b80d8
the storage of !dbg metadata kinds in the instruction themselves.
The on-the-side hash table works great for metadata that not-all
instructions get, or for metadata that only exists when optimizing.
But when compile-time is everything, it isn't great.
I'm not super thrilled with the fact that this plops a TrackingVH in
Instruction, because it grows it by 3 words. I'm investigating
alternatives, but this should be a step in the right direction in any
case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99957 91177308-0d34-0410-b5e6-96231b3b80d8
Tested: clang debug bootstrap, llvm-gcc bootstrap, `make check-lit`
after configuring with --with-llvmgccdir (and this did run the
FrontendC* tests this time)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98410 91177308-0d34-0410-b5e6-96231b3b80d8
