As this is the expected behavior of the old darwin otool(1) for ARM Mach-O files.

rdar://25896249

llvm-svn: 267929

We now read out the rest of the substreams from the DBI streams.  One of
these substreams, the FileInfo substream, contains information about which
source files contribute to each module (aka compiland).  This patch
additionally parses out the file information from that substream, and
dumps it in llvm-pdbdump.

Differential Revision: http://reviews.llvm.org/D19634
Reviewed by: ruiu

llvm-svn: 267928

Revert "[Power9] Implement add-pc, multiply-add, modulo, extend-sign-shift, random number, set bool, and dfp test significance".
This patch has caused a functional regression in SPEC2k6 namd, and a performance regression in mesa-pipe.

llvm-svn: 267927

llvm-svn: 267926

Unsigned compare-equal instructions are mapped to signed compare-equal.

llvm-svn: 267925

Add a path note indicating the location of the non-localized string
literal in NonLocalizedStringChecker.

rdar://problem/25981525

llvm-svn: 267924

Summary:
Started failing after rL267895.
Possibly related to http://llvm.org/pr27510.

Reviewers: labath, tfiala

Subscribers: lldb-commits

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

llvm-svn: 267923

llvm-svn: 267922

Using multiple context used to be a really big memory saving because we
could free memory from each file while the linker proceeded with the
symbol resolution. We are getting lazier about reading data from the
bitcode, so I was curious if this was still a good tradeoff.

One thing that is a bit annoying is that we still have to copy the
symbol names. The problem is that the names are stored in the Module and
get freed when we move the module bits during linking.

Long term I think the solution is to add a symbol table to the bitcode.
That way IRObject file will not need to use a Module or a Context and we
can drop it while still keeping a StringRef to the names.

This patch is still be an interesting medium term improvement.

When linking llvm-as without debug info this patch is a small speedup:

master: 29.861877513 seconds
patch: 29.814533787 seconds

With debug info the numbers are

master: 34.765181469 seconds
patch: 34.563351584 seconds

The peak memory usage when linking llvm-as with debug info was

master: 599.10MB
patch: 600.13MB
llvm-svn: 267921

Visual C++ 2015 flags this in the IDE.

llvm-svn: 267919

ScheduleDAGMI::initQueues changes the RegionBegin to the first non-debug
instruction. Since it does not track register pressure, it does not affect
any RP trackers. ScheduleDAGMILive inherits initQueues from ScheduleDAGMI,
and it does reset the TopTPTracker in its schedule method. Any derived,
target-specific scheduler will need to do it as well, but the TopRPTracker
is only exposed as a "const" object to derived classes. Without the ability
to modify the tracker directly, this leaves a derived scheduler with a
potential of having the TopRPTracker out-of-sync with the CurrentTop.

The symptom of the problem:
  void llvm::ScheduleDAGMILive::scheduleMI(llvm::SUnit *, bool):
  Assertion `TopRPTracker.getPos() == CurrentTop && "out of sync"' failed.

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

llvm-svn: 267918

Relocations against sections with no SHF_ALLOC bit are R_ABS relocations.
Currently we are creating Relocations vector for them, but that is wasteful.
This patch is to skip vector construction and to directly apply relocations
in place.

This patch seems to be pretty effective for large executables with debug info.
r266158 (Rafael's patch to change the way how we apply relocations) caused a
temporary performance degradation for such executables, but this patch makes
it even faster than before.

Time to link clang with debug info (output size is 1070 MB):

  before r266158: 15.312 seconds (0%)
  r266158:        17.301 seconds (+13.0%)
  Head:           16.484 seconds (+7.7%)
  w/patch:        13.166 seconds (-14.0%)

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

llvm-svn: 267917

The canonical form for allocas is a single allocation of the array type.
In case we see a non-canonical array alloca, make sure we aren't
replacing this with an array N times smaller.

llvm-svn: 267916

llvm-svn: 267915

PresumedLoc should not be called.

llvm-svn: 267914

Changing the Apple CMake cache file to better match the way Apple Clang builds are built.

llvm-svn: 267913

This happens to be working now because the includes exist in another CMake file that is included before this one. That will change with upcoming refactoring.

llvm-svn: 267912

http://reviews.llvm.org/D19671

llvm-svn: 267911

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

llvm-svn: 267910

llvm-svn: 267909

Should not store Twine objects to local variables. This is fixed the test
failures with r267815 in VS2015 X64 build.

llvm-svn: 267908

On Darwin, MAP_ANONYMOUS is a synonym for MAP_ANON. However, some SDK's
don't define MAP_ANONYMOUS. Use MAP_ANON to work around this.

(As a point of interest, the situation is exactly reversed on Linux.)

llvm-svn: 267907

When comparing unqualified types, canonical types should be used, otherwise equivalent types may be treated as different type.

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

llvm-svn: 267906

llvm-svn: 267905

The LLVM Verifier expects all inlinable calls in debuggable functions to
have a location.

rdar://problem/25818489

llvm-svn: 267904

I have updated the compiler-rt tests.

llvm-svn: 267903

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

llvm-svn: 267902

Specifically:
  Vd = #0   -> Vd = vxor(Vd, Vd)
  Vdd = #0  -> Vdd.w = vsub(Vdd.w, Vdd.w)
  Vdd = Vss -> Vdd = vcombine(Vss.H, Vss.L)

llvm-svn: 267901

Currently Mips::emitAtomicBinaryPartword() does not properly respect the
width of pointers. For MIPS64 this causes the memory address that the ll/sc
sequence uses to be truncated. At runtime this causes a segmentation fault.

This can be fixed by applying similar changes as r266204, so that a full 64bit
pointer is loaded.

Reviewers: dsanders

Differential Review: http://reviews.llvm.org/D19651

llvm-svn: 267900

The refactoring portion part was done as r267748.

http://reviews.llvm.org/D14185

llvm-svn: 267899

Differential Revision: http://reviews.llvm.org/D18828
Patch by Aditya Kumar!

llvm-svn: 267898

Patch by Colin LeMahieu.

llvm-svn: 267897

The DWARF2 specification of DW_AT_bit_offset is ambiguous for
little-endian machines, but by restoring to the old behavior
we match what debuggers expect and what other popular compilers
generate.

llvm-svn: 267896

The DWARF2 specification of DW_AT_bit_offset was written from the perspective of
a big-endian machine with unclear semantics for other systems.  DWARF4
deprecated DW_AT_bit_offset and introduced a new attribute DW_AT_data_bit_offset
that simply counts the number of bits from the beginning of the containing
entity regardless of endianness.

After this patch LLVM emits DW_AT_bit_offset for DWARF 2 or 3 and
DW_AT_data_bit_offset when DWARF 4 or later is requested.

llvm-svn: 267895

llvm-svn: 267894

Made in preparation for adding MemorySSA support to EarlyCSE.

llvm-svn: 267893

Reviewers: kcc

Subscribers: llvm-commits

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

llvm-svn: 267892

When updating the graph, make sure that new uses without reaching defs
are handled correctly.

llvm-svn: 267891

Reviewers: mcrosier

Subscribers: mcrosier, llvm-commits

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

llvm-svn: 267890

llvm-svn: 267889