llvm-svn: 191818

llvm-svn: 191817

llvm-svn: 191816

llvm-svn: 191815

libcxx doesn't build with -Werror because of #warnings in its source
code. But when libcxx is built as an external LLVM project, it inherits
LLVM build flags, breaking the build if LLVM_ENABLE_WERROR is enabled.

llvm-svn: 191814

llvm-svn: 191813

otherwise encoding fails after the last change in X86MCCodeEmitter.cpp.

llvm-svn: 191812

aren't yet happy with this config.

llvm-svn: 191811

llvm-svn: 191810

llvm-svn: 191809

when scalars are loaded / undergo lvalue-to-rvalue conversion.

llvm-svn: 191808

llvm-svn: 191807

llvm-svn: 191806

Also add some tests that there is actually a message and that the bug is
actually a hard error. This actually behaved correctly before, because:

- addTransition() doesn't actually add a transition if the new state is null;
  it assumes you want to propagate the predecessor forward and does nothing.
- generateSink() is called in order to emit a bug report.
- If at least one new node has been generated, the predecessor node is /not/
  propagated forward.

But now it's spelled out explicitly.

Found by Richard Mazorodze, who's working on a patch that may require this.

llvm-svn: 191805

This threads SectionName through the allocateCodeSection/allocateDataSection APIs, both in C++ and C land.  
It's useful for the memory managers that are allocating a section to know what the name of the section is.  
At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what 
memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about 
what each allocation is for.  This allows clients that supply their own memory managers to do this.  
Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM 
client.

This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM.  I'm assuming that 
it's safe to change the C++ API because that API is allowed to change.  I'm assuming that it's safe to change 
the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory 
management C API).

llvm-svn: 191804

back in r173096 by Greg.  When constructing a g packet or parsing a G packet,
and we're iterate over our register list, skip registers that are actually
just slices of other, real, registers.  For instance, eax is 32-bits of rax
on x86_64.
<rdar://problem/15104187> 

llvm-svn: 191802

DW_TAG_pointer_type is updated to use DITypeRef.

Paired commit with r191800.

llvm-svn: 191801

is updated to use DITypeRef.

Move isUnsignedDIType and getOriginalTypeSize from DebugInfo.h to be static
helper functions in DwarfCompileUnit. We already have a static helper function
"isTypeSigned" in DwarfCompileUnit, and a pointer to DwarfDebug is added to
resolve the derived-from field. All three functions need to go across link
for derived-from fields, so we need to get hold of a type identifier map.

A pointer to DwarfDebug is also added to DbgVariable in order to resolve the
derived-from field.

Debug info verifier is updated to check a derived-from field is a TypeRef.
Verifier will not go across link for derived-from fields, in debug info finder,
we go across the link to add derived-from fields to types.

Function getDICompositeType is only used by dragonegg and since dragonegg does
not generate identifier for types, we use an empty map to resolve the
derived-from field.

When printing a derived-from field, we use DITypeRef::getName to either return
the type identifier or getName of the DIType.

A paired commit at clang is required due to changes to DIBuilder.

llvm-svn: 191800

comments issued with verbose assembly.
E.g., on a vector shuffle operation, disassembled output are:
* Without the option:
vpshufd $-0x79, (%rsp), %xmm0

* With the option:
vpshufd $-0x79, (%rsp), %xmm0   ## xmm0 = mem[3,1,0,2]

This part of <rdar://problem/14687488>.

llvm-svn: 191799

llvm-svn: 191798

that had 80-column violations. Remove spurious emacs mode markers on .cpp files.

llvm-svn: 191797

migration of headers which have become system headers by user having put
the .system_framework in the sdk directory.
// rdar://15066802

llvm-svn: 191796

llvm-svn: 191794

llvm-svn: 191793

and it is shared across CUs.

We add a few maps in DwarfDebug to map MDNodes for the type system to the
corresponding DIEs: MDTypeNodeToDieMap, MDSPNodeToDieMap, and
MDStaticMemberNodeToDieMap. These DIEs can be shared across CUs, that is why we
keep the maps in DwarfDebug instead of CompileUnit.

Sometimes, when we try to add an attribute to a DIE, the DIE is not yet added
to its owner yet, so we don't know whether we should use ref_addr or ref4.
We create a worklist that will be processed during finalization to add
attributes with the correct form (ref_addr or ref4).

We add addDIEEntry to DwarfDebug to be a wrapper around DIE->addValue. It checks
whether we know the correct form, if not, we update the worklist
(DIEEntryWorklist).

A testing case is added to show that we only create a single DIE for a type
MDNode and we use ref_addr to refer to the type DIE.

llvm-svn: 191792

llvm-svn: 191790

llvm-svn: 191789

llvm-svn: 191788

that each comment ends with a newline to match the definition in the header
file.

This is part of <rdar://problem/14687488>.

llvm-svn: 191787

It's silly to merge functions like these:

define void @foo(i32 %x) {
  ret void
}

define void @bar(i32 %x) {
  ret void
}

to get

define void @bar(i32) {
  tail call void @foo(i32 %0)
  ret void
}

llvm-svn: 191786

The use of these features in clang has been reverted.

llvm-svn: 191785

The added a cmake invocation to null builds, making them a lot slower.

llvm-svn: 191784

llvm-svn: 191783

Thanks for Dimitry Andric, Rafael Espindola, and Benjamin Kramer
for providing and progressively reducing the test case!

llvm-svn: 191782

Parsing .debug_aranges section now takes O(nlogn) operations instead
of O(n^2), where "n" is the number of address ranges. With this change,
the time required to symbolize an address from a random large
Clang-generated binary drops from 165 seconds to 1.5 seconds.

No functionality change.

llvm-svn: 191781

llvm-svn: 191780

llvm-svn: 191779

llvm-svn: 191778

llvm-svn: 191777

Replacements were no applied when using a compilation database with paths in the
compilation command relative to the compile directory. This patch makes those
paths abosulte.

llvm-svn: 191776