DWARF parser: Use ArrayRef to represent form sizes and simplify DWARFDIE::extractFast() interface. No functionality change.

llvm-svn: 193560

llvm-mcmarkup, obj2yaml and yaml2obj were missing from the substitutions list,
causing the test suite to fail in a sandboxed environment.

llvm-svn: 193559

llvm-svn: 193558

llvm-svn: 193557

This change has no effect now, but will be needed to emit BSS atoms
to .bss section.

llvm-svn: 193556

llvm-svn: 193555

This reverts commit r193528 (and fixes).

It broke Chandler's setup.

llvm-svn: 193554

Summary:
Use DWARF4 table of form classes to fetch attributes from DIE
in a more consistent way. This shouldn't change the functionality and
serves as a refactoring for upcoming change: DW_AT_high_pc has different
semantics depending on its form class.

Reviewers: dblaikie, echristo

Reviewed By: echristo

CC: echristo, llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1961

llvm-svn: 193553

llvm-svn: 193552

llvm-svn: 193551

llvm-svn: 193550

  requires ! feature

The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).

llvm-svn: 193549

llvm-svn: 193548

llvm-svn: 193547

llvm-svn: 193546

statement (after a case label, if, etc). Patch by Olivier Goffart!

llvm-svn: 193545

llvm-svn: 193544

llvm-svn: 193543

llvm-svn: 193542

llvm-svn: 193541

No functionality change.

llvm-svn: 193540

llvm-svn: 193539

llvm-svn: 193538

llvm-svn: 193537

llvm-svn: 193536

an MCExpr, in order to avoid writing an encoded zero value in the immediate
field.

When getUnconditionalBranchTargetOpValue is called with an MCExpr target, we
don't know what the final immediate field value should be. We shouldn't
explicitly set the immediate field to an encoded zero value as zero is encoded
with a non-zero bit pattern. This leads to bits being set that pollute the
final immediate value. The nature of the encoding is such that the polluted
bits only affect very large immediate values, explaining why this hasn't
caused problems earlier.

Fixes <rdar://problem/15155975>.

llvm-svn: 193535

llvm-svn: 193534

llvm-svn: 193533

llvm-svn: 193532

<rdar://problem/15208799>

llvm-svn: 193530

llvm-svn: 193529

With this patch we correctly determine that ubuntu's ARM tree is not biarch
and use "lib" istead of "lib32".

Without this patch the search inside the arm tree for the crt files was failing
and we would end up trying to use the i686 ones in lib32.

llvm-svn: 193528

llvm-svn: 193527

llvm-svn: 193526

These used to be referenced by the CGI->AWI map (in AsmWriterEmitter), but
stored in a vector local to EmitPrintInstruction. Move the vector to
AsmWriterEmitter too.

llvm-svn: 193525

This commit allows the ARM integrated assembler to parse
and assemble the code with .eabi_attribute, .cpu, and
.fpu directives.

To implement the feature, this commit moves the code from
AttrEmitter to ARMTargetStreamers, and several new test
cases related to cortex-m4, cortex-r5, and cortex-a15 are
added.

Besides, this commit also change the Subtarget->isFPOnlySP()
to Subtarget->hasD16() to match the usage of .fpu directive.

This commit changes the test cases:

* Several .eabi_attribute directives in
  2010-09-29-mc-asm-header-test.ll are removed because the .fpu
  directive already cover the functionality.

* In the Cortex-A15 test case, the value for
  Tag_Advanced_SIMD_arch has be changed from 1 to 2,
  which is more precise.

llvm-svn: 193524

llvm-svn: 193523

llvm-svn: 193522

useAA significantly improves the handling of vector code that has TBAA
information attached.  It also helps other cases, as shown by the testsuite
changes here.  The only real downside I've seen is that it interferes with
MergeConsecutiveStores.  The problem is that that optimization works top
down, starting at the first store in the chain, and looks for cases where
the chain result is only used by a single related store.  These related
stores don't alias, so useAA will have rewritten all the later stores to
use a different chain input (typically the same one as the first store).

I think the advantages outweigh the disadvantages though, so for now I've
just disabled alias analysis for the unaligned-01.ll test.

llvm-svn: 193521

this makes the reports consistent with tsan, and much more readable.

llvm-svn: 193520