| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.
I'll be updating other docs and other files in smaller subsequnet
commits.
While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.
Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)
llvm-svn: 171359
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
| |
llvm-svn: 161826
|
|
|
|
|
|
|
| |
There are other passes, BBVectorize specifically, that also need some of
this functionality.
llvm-svn: 158605
|
|
|
|
|
|
| |
MDNodeOperand value.
llvm-svn: 155599
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FoldingSet is implemented as a chained hash table. When there is a hash
collision during insertion, which is common as we fill the table until a
load factor of 2.0 is hit, we walk the chained elements, comparing every
operand with the new element's operands. This can be very expensive if the
MDNode has many operands.
We sacrifice a word of space in MDNode to cache the full hash value, reducing
compares on collision to a minimum. MDNode grows from 28 to 32 bytes + operands
on x86. On x86_64 the new bits fit nicely into existing padding, not growing
the struct at all.
The actual speedup depends a lot on the test case and is typically between
1% and 2% for C++ code with clang -c -O0 -g.
llvm-svn: 154497
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringMap. This was redundant and unnecessarily bloated the MDString class.
Because the MDString class is a "Value" and will never have a "name", and
because the Name field in the Value class is a pointer to a StringMap entry, we
repurpose the Name field for an MDString. It stores the StringMap entry in the
Name field, and uses the normal methods to get the string (name) back.
PR12474
llvm-svn: 154429
|
|
|
|
|
|
|
|
|
|
|
|
| |
An MDNode has a list of MDNodeOperands allocated directly after it as part of
its allocation. Therefore, the Parent of the MDNodeOperands can be found by
walking back through the operands to the beginning of that list. Mark the first
operand's value pointer as being the 'first' operand so that we know where the
beginning of said list is.
This saves a *lot* of space during LTO with -O0 -g flags.
llvm-svn: 154280
|
|
|
|
|
|
| |
testing machine.
llvm-svn: 153951
|
|
|
|
|
|
| |
speedup.
llvm-svn: 153949
|
|
|
|
|
|
| |
node and returning it if one didn't exist.
llvm-svn: 153798
|
|
|
|
|
|
|
| |
used to incrementally update a created node without needing a
temporary node and RAUW.
llvm-svn: 150571
|
|
|
|
| |
llvm-svn: 148578
|
|
|
|
|
|
|
|
| |
there is non of that type to remove. This fixes a crasher in the particular
case where the instruction has metadata but no metadata storage in the context
(this is only possible if the instruction has !dbg but no other metadata info).
llvm-svn: 147285
|
|
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146960
|
|
|
|
| |
llvm-svn: 145934
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 134829
|
|
|
|
| |
llvm-svn: 129932
|
|
|
|
| |
llvm-svn: 126978
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 114996
|
|
|
|
|
|
| |
it's not used afterwards.
llvm-svn: 114986
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 113828
|
|
|
|
|
|
| |
is-function-local flag in metadata uniquing bits.
llvm-svn: 112528
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 111995
|
|
|
|
|
|
| |
MDNode::deleteTemporary.
llvm-svn: 111853
|
|
|
|
| |
llvm-svn: 111739
|
|
|
|
|
|
| |
is not non-temporary.
llvm-svn: 111713
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 111681
|
|
|
|
|
|
| |
for creating and populating NamedMDNodes.
llvm-svn: 109061
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 109028
|
|
|
|
|
|
| |
referenced by NamedMDNodes shouldn't be deleted.
llvm-svn: 109021
|
|
|
|
| |
llvm-svn: 109020
|
|
|
|
|
|
|
| |
it to just do the things that need to be done when an instruction
is deleted.
llvm-svn: 108948
|
|
|
|
|
|
| |
replaced with setDebugLoc and getDebugLoc.
llvm-svn: 108914
|
|
|
|
| |
llvm-svn: 108259
|
|
|
|
| |
llvm-svn: 107697
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 103008
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 103007
|
|
|
|
|
|
|
| |
metadata references in non-function-local MDNodes should drop to
null.
llvm-svn: 102519
|
|
|
|
|
|
|
| |
This keeps around temporary typedef for clang/llvm-gcc so the
build won't break when I commit this :)
llvm-svn: 100218
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 100088
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 99982
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 99957
|
|
|
|
| |
llvm-svn: 99927
|
|
|
|
| |
llvm-svn: 99490
|
|
|
|
| |
llvm-svn: 99484
|
|
|
|
|
|
|
|
|
|
| |
r97788.
Tested: clang debug bootstrap, llvm-gcc bootstrap, `make check-lit`
after configuring with --with-llvmgccdir (and this did run the
FrontendC* tests this time)
llvm-svn: 98410
|
|
|
|
| |
llvm-svn: 98156
|
|
|
|
|
|
| |
the FrontendC* tests. :(
llvm-svn: 97921
|
|
|
|
|
|
| |
bootstraps llvm-gcc this time.
llvm-svn: 97918
|