ELF with support for:

- File headers
- Section headers + data
- Relocations
- Symbols
- Unwind data (only COFF/Win64)

The output format follows a few rules:
- Values are almost always output one per line (as elf-dump/coff-dump already do). - Many values are translated to something readable (like enum names), with the raw value in parentheses.
- Hex numbers are output in uppercase, prefixed with "0x".
- Flags are sorted alphabetically.
- Lists and groups are always delimited.

Example output:
---------- snip ----------
Sections [
  Section {
    Index: 1
    Name: .text (5)
    Type: SHT_PROGBITS (0x1)
    Flags [ (0x6)
      SHF_ALLOC (0x2)
      SHF_EXECINSTR (0x4)
    ]
    Address: 0x0
    Offset: 0x40
    Size: 33
    Link: 0
    Info: 0
    AddressAlignment: 16
    EntrySize: 0
    Relocations [
      0x6 R_386_32 .rodata.str1.1 0x0
      0xB R_386_PC32 puts 0x0
      0x12 R_386_32 .rodata.str1.1 0x0
      0x17 R_386_PC32 puts 0x0
    ]
    SectionData (
      0000: 83EC04C7 04240000 0000E8FC FFFFFFC7  |.....$..........|
      0010: 04240600 0000E8FC FFFFFF31 C083C404  |.$.........1....|
      0020: C3                                   |.|
    )
  }
]
---------- snip ----------

Relocations and symbols can be output standalone or together with the section header as displayed in the example.
This feature set supports all tests in test/MC/COFF and test/MC/ELF (and I suspect all additional tests using elf-dump), making elf-dump and coff-dump deprecated.

Patch by Nico Rieck!

llvm-svn: 178679

Patch by Nico Rieck!

llvm-svn: 178678

Patch by Nico Rieck!

llvm-svn: 178677

Patch by Nico Rieck!

llvm-svn: 178676

llvm-svn: 178675

llvm-svn: 178674

Incorporating review feedback from Bill Schmidt on r178617. No functionality
change intended.

llvm-svn: 178672

llvm-svn: 178667

Testing for Visual Studio 2010 SP1 or greater before calling the _xgetbv intrinsic.  This also fixes a minor code formatting issue.

llvm-svn: 178666

llvm-svn: 178665

Mesa does not override llvm behavior wrt KILLGT anymore so llvm
has to handle KILLGT on its own.

llvm-svn: 178664

llvm-svn: 178662

I discussed this with Bill Schmidt on IRC, and it was decided that this is a
safe and reasonable default.

llvm-svn: 178659

llvm-svn: 178658

llvm-svn: 178657

More direct types in PowerPC AltiVec intrinsics.

This patch follows up on work done by Bill Schmidt in r178277,
and replaces most of the remaining uses of VRRC in ISEL DAG patterns.

The resulting .inc files are identical except for comments, so
no change in code generation is expected.

llvm-svn: 178656

For this we need to use a libcall.  Previously LLVM didn't implement
libcall support for frem, so I've added it in the usual
straightforward manner.  A test case from the bug report is included.

llvm-svn: 178639

llvm-svn: 178637

when getting the host processor information.  It emits a .byte sequence on GNUC compilers to work around lack of xgetbv support with older assemblers, and resolves a comment typo found in the previous patch.

llvm-svn: 178636

llvm-svn: 178635

llvm-svn: 178634

It's a bit of churn in the blame log, but I think there are real benefits to
the newer system so I'm making the change in one go.

llvm-svn: 178633

llvm-svn: 178624

llvm-svn: 178623

The same compare instruction is used for 32-bit and 64-bit compares. It
sets two different sets of flags: icc and xcc.

This patch adds a conditional branch instruction using the xcc flags for
64-bit compares.

llvm-svn: 178621

These refer to the reciprocal estimate support recently committed.

llvm-svn: 178618

When unsafe FP math operations are enabled, we can use the fre[s] and
frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together
with some Newton iteration, in order to quickly generate floating-point
division and sqrt results. All of these instructions are separately optional,
and so each has its own feature flag (except for the Altivec instructions,
which are covered under the existing Altivec flag). Doing this is not only
faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these
computations to be pipelined with other computations in order to hide their
overall latency.

I've also added a couple of missing fnmsub patterns which turned out to be
missing (but are necessary for good code generation of the Newton iterations).
Altivec needs a similar fix, but that will probably be more complicated because
fneg is expanded for Altivec's v4f32.

llvm-svn: 178617

This finally fixes the encoding. The patch also
* Removes eh-frame.ll. It was an unnecessary .ll to .o test that was checking
  the wrong value.
* Merge fde-reloc.s and eh-frame.s into a single test, since the only difference
  was the run lines.
* Don't blindly test the content of the entire .eh_frame section. It makes it
  hard to anyone actually fixing a bug and hitting a difference in a binary
  blob. Instead, use a CHECK for each field and document what is being checked.

llvm-svn: 178615

Rolling back the AVX support patch due to breaking a gcc 4.6 build bot that doesn't understand the xgetbv instruction for some reason.  Will revisit when time permits.

llvm-svn: 178614

Remove an optimization where we were changing an objc_autorelease into an objc_autoreleaseReturnValue.

The semantics of ARC implies that a pointer passed into an objc_autorelease
must live until some point (potentially down the stack) where an
autorelease pool is popped. On the other hand, an
objc_autoreleaseReturnValue just signifies that the object must live
until the end of the given function at least.

Thus objc_autorelease is stronger than objc_autoreleaseReturnValue in
terms of the semantics of ARC* implying that performing the given
strength reduction without any knowledge of how this relates to
the autorelease pool pop that is further up the stack violates the
semantics of ARC.

*Even though objc_autoreleaseReturnValue if you know that no RV
optimization will occur is more computationally expensive.

llvm-svn: 178612

llvm-svn: 178605

llvm-svn: 178604

Looks like the gcc in http://lab.llvm.org:8011/builders/clang-x86_64-darwin11-self-mingw32/ doesn't like "not external linkage":

/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/include/llvm/Support/YAMLTraits.h: In instantiation of 'const bool llvm::yaml::has_SequenceMethodTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >::value':
/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/include/llvm/Support/YAMLTraits.h:281:   instantiated from 'llvm::yaml::has_SequenceTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >'
/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/utils/yaml2obj/yaml2obj.cpp:627:   instantiated from here
/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/include/llvm/Support/YAMLTraits.h:243: error: 'llvm::yaml::SequenceTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >::size' is not a valid template argument for type 'size_t (*)(llvm::yaml::IO&, std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> >&)' because function 'static size_t llvm::yaml::SequenceTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >::size(llvm::yaml::IO&, std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> >&)' has not external linkage

llvm-svn: 178600

when getting the host processor information.

llvm-svn: 178598

The generic structs and specializations will be refactored when obj2yaml is
changed to use yaml::IO.

llvm-svn: 178593

llvm-svn: 178589

This patch initializes t9 to the handler address, but only if the relocation
model is pic. This handles the case where handler to which eh.return jumps 
points to the start of the function.

Patch by Sasa Stankovic.

llvm-svn: 178588

llvm-svn: 178586

llvm-svn: 178585

This patch fixes the following two tests which have been failing on
llvm-mips-linux builder since r178403:

LLVM :: Analysis/Profiling/load-branch-weights-ifs.ll
LLVM :: Analysis/Profiling/load-branch-weights-loops.ll

llvm-svn: 178584