llvm-svn: 157060

Part of rdar://11352000 and should bring the buildbots back.

llvm-svn: 156421

Patch by Jack Carter.

llvm-svn: 156409

Part of rdar://11352000

llvm-svn: 156405

llvm-svn: 154878

- Don't copy offsets into HashData, the underlying vector won't change once the table is finalized.
- Allocate HashData and HashDataContents in a BumpPtrAllocator.
- Allocate string map entries in the same allocator.
- Random cleanups.

llvm-svn: 154694

This enables debuggers to see what are interesting lines for a
breakpoint rather than any line that starts a function.

rdar://9852092

llvm-svn: 154120

might have more than 19 operands. Add a testcase to make sure I
never screw that up again.

Part of rdar://11026482

llvm-svn: 153961

brace) so that we get more accurate line number information about the
declaration of a given function and the line where the function
first starts.

Part of rdar://11026482

llvm-svn: 153916

llvm-svn: 153880

http://llvm.org/docs/SourceLevelDebugging.html#objcproperty

including type and DECL. Expand the metadata needed accordingly.

rdar://11144023

llvm-svn: 153639

and not the rest of the member tag.

Fixes PR11695

llvm-svn: 153570

Fixes PR10105

llvm-svn: 153524

backtrace locations.

Testcase forthcoming, but I wanted to get some testing here.

Should fix:

PR12323
PR12314
rdar://11091100

llvm-svn: 153471

llvm-svn: 153438

llvm-svn: 153429

Dump the hex representation to the comment stream as well as the float
value.

llvm-svn: 153346

metadata operand as an actual operand, leading to an assert. Error
out in this case.

rdar://11007633

llvm-svn: 153234

i128). In that case, we may not be able to print out the MCExpr as an
expression. For instance, we could have an MCExpr like this:

    0xBEEF0000BEEF0000 | (0xBEEF0000BEEF0000 << 64)

The MCExpr printer handles sizes up to 64-bits, but this expression would
require 128-bits. In this situation, try to evaluate the constant expression and
emit that as the value into 64-bit chunks.
<rdar://problem/11070338>

llvm-svn: 153081

the DECL information.

rdar://10855921

llvm-svn: 152876

out the DW_AT_name. Older gdbs unfortunately still use it to
disambiguate member functions in templated classes (gdb.cp/templates.exp).

rdar://11043421 (which is now deferred for a bit)

llvm-svn: 152782

output (we're emitting a specification already and the information
isn't changing).

Saves 1% on the debug information for a build of llvm.

Fixes rdar://11043421

llvm-svn: 152697

DwarfDebug: Store the filename/dirname pair as a zero-separated string in a stringmap, instead of using a highly inefficient std::map of a pair of std::strings.

llvm-svn: 152541

as well as completely defined classes.

This fixes rdar://10956070

llvm-svn: 152171

llvm-svn: 152153

llvm-svn: 152016

llvm-svn: 152001

llvm-svn: 151875

llvm-svn: 151874

to the string table for the function name, not the function name.

llvm-svn: 151873

The inline table needs to be constructed ahead of time so that it doesn't try to
create new strings while we're emitting everything.

This reverts commit a8ff9bccb399183cdd5f1c3cec2bda763664b4b0.

llvm-svn: 151864

fixups that are being used to determine section offsets. Reduces
the total number of fixups by 50% for a non-trivial testcase.

Part of rdar://10413936

llvm-svn: 151852

llvm-svn: 151849

The standard function epilog includes a .size directive, but ppc64 uses
an alternate local symbol to tag the actual start of each function.

Until recently, binutils accepted the .size directive as:
 .size	test1, .Ltmp0-test1
however, using this directive with recent binutils will result in the error:
 .size expression for XXX does not evaluate to a constant
so we must use the label which actually tags the start of the function.

llvm-svn: 151200

Worth another 45k (1%) off of a large C++ testcase.

rdar://10909458

llvm-svn: 151144

llvm-svn: 151143

llvm-svn: 151142

Part of rdar://10493979 where it reduces by about .5% (10k)

llvm-svn: 151097

method. This allows the target lowering code to not have to deal with MDNodes.

Also, avoid leaking memory like a sieve by not creating a global variable for
the image info section, but just emitting the code directly.

llvm-svn: 150624

The MachO back-end needs to emit the garbage collection flags specified in the
module flags. This is a WIP, so the front-end hasn't been modified to emit these
flags just yet. Documentation and front-end switching to occur soon.

llvm-svn: 150507