| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Luckily this never was released.
llvm-svn: 97857
|
|
|
|
| |
llvm-svn: 97856
|
|
|
|
| |
llvm-svn: 97608
|
|
|
|
|
|
|
|
|
| |
keep track of instructions that return void) per-function. This fixes PR5278.
This breaks backwards compatibility with the metadata format. That's okay
because we haven't released the metadata bitcode yet.
llvm-svn: 97132
|
|
|
|
|
|
|
| |
and T->isPointerTy(). Convert most instances of the first form to the second form.
Requested by Chris.
llvm-svn: 96344
|
|
|
|
| |
llvm-svn: 96269
|
|
|
|
|
|
| |
isInteger, we now have isFloatTy and isIntegerTy. Requested by Chris!
llvm-svn: 96223
|
|
|
|
| |
llvm-svn: 96011
|
|
|
|
| |
llvm-svn: 96008
|
|
|
|
| |
llvm-svn: 96006
|
|
|
|
|
|
| |
to function-local IR were not getting written by BitcodeWriter; solution is for these metadata to be enumerated just like global metadata.
llvm-svn: 95467
|
|
|
|
|
|
| |
that it refers to; fix is to not enumerate operands of function-local metadata until after all instructions have been enumerated
llvm-svn: 95269
|
|
|
|
|
|
| |
been erased (making it not have any more function-local operands)
llvm-svn: 94842
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.
Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods. The bindings to
other languages still use the ModuleProvider concept. It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.
Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
llvm-svn: 94686
|
|
|
|
|
|
| |
of a forward-reference, which doesn't use an "abbrev" encoding.
llvm-svn: 94454
|
|
|
|
| |
llvm-svn: 94378
|
|
|
|
| |
llvm-svn: 94304
|
|
|
|
| |
llvm-svn: 94243
|
|
|
|
|
|
|
|
|
|
|
| |
missing ones are libsupport, libsystem and libvmcore. libvmcore is
currently blocked on bugpoint, which uses EH. Once it stops using
EH, we can switch it off.
This #if 0's out 3 unit tests, because gtest requires RTTI information.
Suggestions welcome on how to fix this.
llvm-svn: 94164
|
|
|
|
|
|
|
|
|
|
| |
if one of the vectors didn't have elements (such as undef). Fixes PR 6096.
Fix an issue in the constant folder where fcmp (<2 x %ty>, <2 x %ty>) would
have <2 x i1> type if constant folding was successful and i1 type if it wasn't.
This exposed a related issue in the bitcode reader.
llvm-svn: 94069
|
|
|
|
| |
llvm-svn: 93446
|
|
|
|
|
|
| |
function-local MD to write based on the function currently being written
llvm-svn: 93441
|
|
|
|
|
|
| |
instructions, so instruction's references to metadata are fully resolved by the time they get written.
llvm-svn: 93403
|
|
|
|
| |
llvm-svn: 93401
|
|
|
|
| |
llvm-svn: 93355
|
|
|
|
| |
llvm-svn: 93339
|
|
|
|
|
|
| |
function-incorporation, global metadata continues to be enumerated during creation of ValueEnumerator
llvm-svn: 93338
|
|
|
|
| |
llvm-svn: 93337
|
|
|
|
|
|
| |
in ValueEnumerator's ValueList during WriteConstants()
llvm-svn: 93289
|
|
|
|
|
|
| |
ValueList
llvm-svn: 93270
|
|
|
|
| |
llvm-svn: 93165
|
|
|
|
|
|
|
|
| |
getWhenValsUnresolved().
Document PFS argument to ParseValID() and ConvertGlobalOrMetadataValIDToValue().
llvm-svn: 93108
|
|
|
|
|
|
|
|
| |
boolean values were distinguishable from integers. The attached patch introduces "typedef int LLVMBool;", and uses LLVMBool instead of int throughout the C API, wherever a boolean value is called for."
Patch by James Y Knight!
llvm-svn: 93079
|
|
|
|
| |
llvm-svn: 93042
|
|
|
|
| |
llvm-svn: 93039
|
|
|
|
|
|
| |
NamedMDNode record.
llvm-svn: 93037
|
|
|
|
| |
llvm-svn: 93032
|
|
|
|
| |
llvm-svn: 92931
|
|
|
|
| |
llvm-svn: 92783
|
|
|
|
| |
llvm-svn: 92761
|
|
|
|
|
|
| |
dereference the type pointer.
llvm-svn: 92726
|
|
|
|
| |
llvm-svn: 92374
|
|
|
|
|
|
|
| |
things that occur in types. "operands" are things that occur
in values.
llvm-svn: 92322
|
|
|
|
| |
llvm-svn: 92320
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
irrelevant internal implementation details to clients.
llvm-svn: 92210
|
|
|
|
| |
llvm-svn: 92208
|