Implement the "linker_private_weak" linkage type. This will be used for
Objective-C metadata types which should be marked as "weak", but which the
linker will remove upon final linkage. However, this

Implement the "linker_private_weak" linkage type. This will be used for
Objective-C metadata types which should be marked as "weak", but which the
linker will remove upon final linkage. However, this linkage isn't specific to
Objective-C.

For example, the "objc_msgSend_fixup_alloc" symbol is defined like this:

.globl l_objc_msgSend_fixup_alloc
.weak_definition l_objc_msgSend_fixup_alloc
.section __DATA, __objc_msgrefs, coalesced
.align 3
l_objc_msgSend_fixup_alloc:
.quad _objc_msgSend_fixup
.quad L_OBJC_METH_VAR_NAME_1

This is different from the "linker_private" linkage type, because it can't have
the metadata defined with ".weak_definition".

Currently only supported on Darwin platforms.

llvm-svn: 107433

show more ...

Revert r107205 and r107207.

llvm-svn: 107215

Introducing the "linker_weak" linkage type. This will be used for Objective-C
metadata types which should be marked as "weak", but which the linker will
remove upon final linkage. For example, the "o

Introducing the "linker_weak" linkage type. This will be used for Objective-C
metadata types which should be marked as "weak", but which the linker will
remove upon final linkage. For example, the "objc_msgSend_fixup_alloc" symbol is
defined like this:

.globl l_objc_msgSend_fixup_alloc
.weak_definition l_objc_msgSend_fixup_alloc
.section __DATA, __objc_msgrefs, coalesced
.align 3
l_objc_msgSend_fixup_alloc:
.quad _objc_msgSend_fixup
.quad L_OBJC_METH_VAR_NAME_1

This is different from the "linker_private" linkage type, because it can't have
the metadata defined with ".weak_definition".

llvm-svn: 107205

show more ...

resort to ArgOperand API

llvm-svn: 106942

Speedup bitcode writer. Do not walk all values for all functions to emit function local metadata. In one testcase, probably worst case scenario, the 70x speed up is seen.

llvm-svn: 105360

Bitcode support for allocas with arbitrary array size types.

llvm-svn: 104915

Don't flush the raw_ostream in llvm::WriteBitcodeToFile; it's at
the wrong level. Clients which need to leave the stream open but
which still require the bitcode bits to be on disk should call
flush

Don't flush the raw_ostream in llvm::WriteBitcodeToFile; it's at
the wrong level. Clients which need to leave the stream open but
which still require the bitcode bits to be on disk should call
flush themselves.

llvm-svn: 104885

show more ...

Don't special-case stdout in llvm::WriteBitcodeToFile; just consider
it to be the caller's responsibility to provide a stream in binary
mode. This fixes a layering violation and avoids an outs() call

Don't special-case stdout in llvm::WriteBitcodeToFile; just consider
it to be the caller's responsibility to provide a stream in binary
mode. This fixes a layering violation and avoids an outs() call.

llvm-svn: 104878

show more ...

Revert 101465, it broke internal OpenGL testing.

Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.

llvm-svn: 101579

reapply r101434
with a fix for self-hosting

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more e

reapply r101434
with a fix for self-hosting

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101465

show more ...

back out r101423 and r101397, they break llvm-gcc self-host on darwin10

llvm-svn: 101434

reapply r101364, which has been backed out in r101368
with a fix

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to

reapply r101364, which has been backed out in r101368
with a fix

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101397

show more ...

back out r101364, as it trips the linux nightlybot on some clang C++ tests

llvm-svn: 101368

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faste

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101364

show more ...

Add special case bitcode support for DebugLoc. This avoids
having the bitcode writer materialize mdnodes for all the
debug location tuples when writing out the bc file and
stores the information in

Add special case bitcode support for DebugLoc. This avoids
having the bitcode writer materialize mdnodes for all the
debug location tuples when writing out the bc file and
stores the information in a more compact form. For example,
the -O0 -g bc file for combine.c in 176.gcc shrinks from
739392 to 512096 bytes.

This concludes my planned short-term debug info work.

llvm-svn: 100261

show more ...

Finally land the InvokeInst operand reordering.
I have audited all getOperandNo calls now, fixing
hidden assumptions. CallSite related uglyness will
be eliminated successively.

Note this patch has a

Finally land the InvokeInst operand reordering.
I have audited all getOperandNo calls now, fixing
hidden assumptions. CallSite related uglyness will
be eliminated successively.

Note this patch has a long and griveous history,
for all the back-and-forths have a look at
CallSite.h's log.

llvm-svn: 99399

show more ...

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