llvm-svn: 265583

This reverts commit r265550. There're problems with endianness on dumping instruction bytes. Need to find out how to use support::ulittle32_t type properly.

llvm-svn: 265554

Differential revision: http://reviews.llvm.org/D16998

llvm-svn: 265550

Revert "Fix Clang-tidy modernize-deprecated-headers warnings in remaining files; other minor fixes."

This reverts commit r265454 since it broke the build.  E.g.:

  http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/22413/

llvm-svn: 265459

(also includes the .test file missing from my previous commit, r265452)

llvm-svn: 265457

Some Include What You Use suggestions were used too.

Use anonymous namespaces in source files.

Differential revision: http://reviews.llvm.org/D18778

llvm-svn: 265454

To start with, handle DW_FORM_string names. Follow up commit will handle
the interesting quirk with type units I was originally aiming for here.

llvm-svn: 265452

As suggested by Rafael - this function no longer returns a value as of r264425.

llvm-svn: 265451

llvm-svn: 265426

This just simplifies the code a bit. More so in lld.

llvm-svn: 265403

Patch by Nicole Mazzuca <npmazzuca@gmail.com>.

Differential Revision: http://reviews.llvm.org/D18736

llvm-svn: 265394

Remove a default parameter value being passed unnecessarily, which
also reduces the changes required when this parameter is changed in
D18763.

Document the remaining non-default bool value passed for another
parameter.

llvm-svn: 265348

This reduces unrelated changes in other patches (such as D18763) when
changes to this file are clang formatted.

llvm-svn: 265346

Support seeding a ValueMap with nullptr for Metadata entries, a
situation I didn't consider in the Metadata/Value split.

I added a ValueMapper::getMappedMD accessor that returns an
Optional<Metadata*> with the mapped (possibly null) metadata.  IRMover
needs to use this to avoid modifying the map when it's checking for
unneeded subprograms.  I updated a call from bugpoint since I find the
new code clearer.

llvm-svn: 265228

This allows the linker to instruct ThinLTO to perform only the
optimization part or only the codegen part of the process.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265113

This is intended to be used for ThinLTO incremental build.

Differential Revision: http://reviews.llvm.org/D18213

This is a recommit of r265095 after fixing the Windows issues.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265111

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265110

This reverts commit r265096, r265095, and r265094.
Windows build is broken, and the validation does not pass.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265102

This is intended to be used for ThinLTO incremental build.

Differential Revision: http://reviews.llvm.org/D18213

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265095

Silencing warnings from MSVC 2015 Update 2. All of these changes silence "C4334 '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)". NFC.

llvm-svn: 264929

llvm-svn: 264860

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html .

1) For Mach-O files the code was not printing the values in hex as is the default.
2) The values printed had leading zeros which they should not have.
3) The address for undefined symbols was printed as spaces instead of 0.
4) With the -A option with posix output for an archive did not use square
brackets around the archive member name.

rdar://25311883 and rdar://25299678

llvm-svn: 264778

llvm-svn: 264731

http://reviews.llvm.org/D18534

llvm-svn: 264693

Personality is copied as part of copyFunctionAttributes, but it is
invalid on a declaration. Remove the personality attribute it the
function body is not cloned.

Also add a verifier run over output modules in the llvm-split tool.

llvm-svn: 264667

A DICompileUnit that is not listed in llvm.dbg.cu will cause assertion
failures and/or crashes in the backend. The Verifier should reject this.

rdar://problem/25369499

llvm-svn: 264657

llvm-svn: 264595

Differential Revision: http://reviews.llvm.org/D16820

llvm-svn: 264591

Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.

Firstly, avoid splitting the big blob into multiple chunks of strings.

r264409 imposed an arbitrary limit to avoid a massive allocation on the
shared 'Record' SmallVector.  The bug with that commit only reproduced
when there were more than "chunk-size" strings.  A test for this would
have been useless long-term, since we're liable to adjust the chunk-size
in the future.

Thus, eliminate the motivation for chunk-ing by storing the string sizes
in the blob.  Here's the layout:

    vbr6: # of strings
    vbr6: offset-to-blob
    blob:
       [vbr6]: string lengths
       [char]: concatenated strings

Secondly, make the output of llvm-bcanalyzer readable.

I noticed when debugging r264409 that llvm-bcanalyzer was outputting a
massive blob all in one line.  Past a small number, the strings were
impossible to split in my head, and the lines were way too long.  This
version adds support in llvm-bcanalyzer for pretty-printing.

    <STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 {
      'abc'
      'def'
      'ghi'
    }

From the original commit:

Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.

llvm-svn: 264551

If you're building dwps from other dwps, it can be hard to track down a
duplicate CU ID if it comes from two compilations of the same file in
different modes, etc. By including the .dwo path (which is hopefully
more unique than the file path) it can help track down where the
duplicates came from.

llvm-svn: 264520

It now return the map instead of an iterator.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264489

llvm-svn: 264425

llvm-svn: 264419

readelf -lW

Differential Revision: http://reviews.llvm.org/D18372

llvm-svn: 264415

This reverts commit r264409 since it failed to bootstrap:
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/8302/

llvm-svn: 264410

Optimize output of MDStrings in bitcode.  This emits them in big blocks
(currently 1024) in a pair of records:
  - BULK_STRING_SIZES: the sizes of the strings in the block, and
  - BULK_STRING_DATA: a single blob, which is the concatenation of all
    the strings.

Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.

I needed to add support for blobs to streaming input to get the test
suite passing.
  - StreamingMemoryObject::getPointer reads ahead and returns the
    address of the blob.
  - To avoid a possible reallocation of StreamingMemoryObject::Bytes,
    BitstreamCursor::readRecord needs to move the call to JumpToEnd
    forward so that getPointer is the last bitstream operation.

llvm-svn: 264409

The motivation for MODULE_CODE_METADATA_VALUES was to enable an
-flto=thin scheme where:

 1. First, one function is cherry-picked from a bitcode file.
 2. Later, another function is cherry-picked.
 3. Later, ...
 4. Finally, the metadata needed by all the previous functions is
    loaded.

This was abandoned in favour of:

 1. Calculate the superset of functions needed from a Module.
 2. Link all functions at once.

Delayed metadata reading no longer serves a purpose.  It also adds
a few complication, since we can't count on metadata being properly
parsed when exiting the BitcodeReader.  After discussing with Teresa, we
agreed to remove it.

The code that depended on this was removed/updated in r264326.

llvm-svn: 264378

Going to be reading the DW_AT_GNU_dwo_name shortly as well, and there
was already enough duplication here that it was worth refactoring
rather than adding even more.

llvm-svn: 264350

llvm-svn: 264349

Summary:
Using leading zeroes allows you to search for "000%" to find non-covered
items.

Differential Revision: http://reviews.llvm.org/D18420

llvm-svn: 264336