backing out r99170 because it still fails on clang-x86_64-darwin10-fnt

llvm-svn: 99171

Now that hopefully all direct accesses to InvokeInst operands are fixed
we can reapply the InvokeInst operand reordering patch. (see r98957).

llvm-svn: 99170

back out r98957, it broke http://smooshlab.apple.com:8010/builders/clang-x86_64-darwin10-fnt/builds/703 in the nightly test suite

llvm-svn: 98958

Recommit r80858 again (which has been backed out in r80871).

This time I did a self-hosted bootstrap on Linux x86-64,
with no problems. Let's see how darwin 64-bit self-hosting
goes. At the first si

Recommit r80858 again (which has been backed out in r80871).

This time I did a self-hosted bootstrap on Linux x86-64,
with no problems. Let's see how darwin 64-bit self-hosting
goes. At the first sign of failure I'll back this out.

Maybe the valgrind bots give me a hint of what may be wrong
(it at all).

llvm-svn: 98957

show more ...

reapply r98656 unmodified, which exposed the asmprinter not
handling constant unions.

llvm-svn: 98680

Revert r98656, its breaking all over the place.

llvm-svn: 98662

improve support for uniontype and ConstantUnion, patch by Tim Northover!

llvm-svn: 98656

Add support for a union type in LLVM IR. Patch by Talin!

llvm-svn: 96011

Also recognize armv6t2-* and armv5te-* triplets.

llvm-svn: 96008

Add ARM bitcode file magic.

llvm-svn: 96006

We were not writing bitcode for function-local metadata whose operands have been erased (making it not have any more function-local operands)

llvm-svn: 94842

Kill ModuleProvider and ghost linkage by inverting the relationship between
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules

Kill ModuleProvider and ghost linkage by inverting the relationship between
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

show more ...

Avoid modifying ValueEnumerator's MD ValueList by choosing which function-local MD to write based on the function currently being written

llvm-svn: 93441

In WriteFunction(), write function-local metadata before we write the instructions, so instruction's references to metadata are fully resolved by the time they get written.

llvm-svn: 93403

Fix comment typo

llvm-svn: 93355

Write function-local metadata as a metadata subblock of a funciton block

llvm-svn: 93339

Revert 93270 pending investigation of how stray non-constant values end up in ValueEnumerator's ValueList during WriteConstants()

llvm-svn: 93289

Make WriteConstants() more robust against stray values in ValueEnumerator's ValueList

llvm-svn: 93270

Compute isFunctionLocal in MDNode ctor or via argument in new function getWhenValsUnresolved().
Document PFS argument to ParseValID() and ConvertGlobalOrMetadataValIDToValue().

llvm-svn: 93108

Use separate namespace for named metadata.

llvm-svn: 92931

Allow null to be an element of NamedMDNode. e.g. !llvm.stuff = !{!0, !1, null}

llvm-svn: 92783

rename "elements" of metadata to "operands". "Elements" are
things that occur in types. "operands" are things that occur
in values.

llvm-svn: 92322

Final step in the metadata API restructuring: move the
getMDKindID/getMDKindNames methods to LLVMContext (and add
convenience methods to Module), eliminating MetadataContext.
Move the state that it

Final step in the metadata API restructuring: move the
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

show more ...

This is a major cleanup of the instruction metadata interfaces that
I asked Devang to do back on Sep 27. Instead of going through the
MetadataContext class with methods like getMD() and getMDs(), ju

This is a major cleanup of the instruction metadata interfaces that
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

show more ...

rename getHandlerNames to getMDKindNames, simplify its interface
and simplify all the clients that use it.

llvm-svn: 92224