| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 97792
|
| |
|
|
| |
llvm-svn: 97788
|
| |
|
|
| |
llvm-svn: 96609
|
| |
|
|
|
|
| |
by metadata (since metadata does not appear in a value's use list)
llvm-svn: 94492
|
| |
|
|
| |
llvm-svn: 94243
|
| |
|
|
| |
llvm-svn: 94100
|
| |
|
|
|
|
| |
values
llvm-svn: 93984
|
| |
|
|
|
|
|
| |
logic enforced in the test case as well, so hopefully it is correct. Please
review Victor.
llvm-svn: 93980
|
| |
|
|
|
|
| |
into getFunctionForValue()
llvm-svn: 93977
|
| |
|
|
|
|
| |
performance-critical code (currently only used by AsmWriter)
llvm-svn: 93802
|
| |
|
|
|
|
| |
Function* variable and smallptrset since function-local metadata cannot be cyclic
llvm-svn: 93762
|
| |
|
|
| |
llvm-svn: 93449
|
| |
|
|
|
|
| |
has function that it is local to.
llvm-svn: 93400
|
| |
|
|
|
|
|
| |
twine can be represented as a single StringRef. Use the new methode to simplify
some twine users.
llvm-svn: 93317
|
| |
|
|
| |
llvm-svn: 93249
|
| |
|
|
| |
llvm-svn: 93247
|
| |
|
|
|
| |
warning: suggest parentheses around ‘&&’ within ‘||’.
llvm-svn: 93121
|
| |
|
|
|
|
|
|
| |
getWhenValsUnresolved().
Document PFS argument to ParseValID() and ConvertGlobalOrMetadataValIDToValue().
llvm-svn: 93108
|
| |
|
|
| |
llvm-svn: 93032
|
| |
|
|
| |
llvm-svn: 92931
|
| |
|
|
| |
llvm-svn: 92761
|
| |
|
|
|
|
|
| |
things that occur in types. "operands" are things that occur
in values.
llvm-svn: 92322
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
after the MDNode in memory. This eliminates the operands
pointer and saves a new[] per node.
Note that the code in DIDerivedType::replaceAllUsesWith is wrong
and quite scary. A MDNode should not be RAUW'd with something
else: this changes all uses of the mdnode, which may not be debug
info related! Debug info should use something non-mdnode for
declarations.
llvm-svn: 92321
|
| |
|
|
|
|
|
|
|
|
|
| |
so can be a huge performance issue when tearing down modules and mdnodes
are not guaranteed to be unique anyway. This speeds up:
$ time ~/llvm/Release/bin/clang gcc.c -w -S -g
from 72 to 35s, where gcc.c is from:
http://people.csail.mit.edu/smcc/projects/single-file-programs/
llvm-svn: 92315
|
| |
|
|
|
|
|
|
| |
getMDKindID/getMDKindNames methods to LLVMContext (and add
convenience methods to Module), eliminating MetadataContext.
Move the state that it maintains out to LLVMContext.
llvm-svn: 92259
|
| |
|
|
| |
llvm-svn: 92255
|
| |
|
|
| |
llvm-svn: 92254
|
| |
|
|
| |
llvm-svn: 92252
|
| |
|
|
|
|
|
|
| |
why one was replaced with the other. Even in the specific case of
debug information, it doesn't make sense to transfer the location over,
this will just result in jumbled loc info.
llvm-svn: 92241
|
| |
|
|
| |
llvm-svn: 92240
|
| |
|
|
|
|
|
|
|
|
|
| |
a convention (shadowing the setter with private forwarding function) to
prevent subclasses from accidentally using it.
This exposed some bogosity in ConstantExprs, which was propaging the
opcode of the constant expr into the NUW/NSW/Exact field in the
getWithOperands/getWithOperandReplaced methods.
llvm-svn: 92239
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I asked Devang to do back on Sep 27. Instead of going through the
MetadataContext class with methods like getMD() and getMDs(), just
ask the instruction directly for its metadata with getMetadata()
and getAllMetadata().
This includes a variety of other fixes and improvements: previously
all Value*'s were bloated because the HasMetadata bit was thrown into
value, adding a 9th bit to a byte. Now this is properly sunk down to
the Instruction class (the only place where it makes sense) and it
will be folded away somewhere soon.
This also fixes some confusion in getMDs and its clients about
whether the returned list is indexed by the MDID or densely packed.
This is now returned sorted and densely packed and the comments make
this clear.
This introduces a number of fixme's which I'll follow up on.
llvm-svn: 92235
|
| |
|
|
|
|
|
| |
doesn't exist already, eliminate registerMDKind. Tidy up a bunch
of random stuff.
llvm-svn: 92225
|
| |
|
|
|
|
| |
and simplify all the clients that use it.
llvm-svn: 92224
|