Needs testcase updates.

llvm-svn: 190000

llvm-svn: 189999

llvm-svn: 189997

llvm-svn: 189995

llvm-svn: 189994

llvm-svn: 189993

llvm-svn: 189992

If the instruction window is < NumRegs/2, pressure tracking is not
likely to be effective. The scheduler has to process a very large
number of tiny blocks. We want this to be fast.

llvm-svn: 189991

llvm-svn: 189990

llvm-svn: 189989

llvm-svn: 189988

Register pressure tracking is half the complexity of the
scheduler. It's useful to be able to turn it off for compile time and
performance comparisons.

llvm-svn: 189987

I am about to patch this code, and this makes the diff far more readable.

llvm-svn: 189982

llvm-svn: 189981

llvm-svn: 189980

llvm-svn: 189979

llvm-svn: 189977

These instructions, such as vmul.f32, require the second source operand to
be in D0-D15 rather than the full D0-D31. When optimizing, make sure to
account for that by constraining the register class of a replacement virtual
register to be compatible with the virtual register(s) it's replacing.

I've been unsuccessful in creating a non-fragile regression test. This issue
was detected by the LLVM nightly test suite running on an A15 (Bullet).

PR17093: http://llvm.org/bugs/show_bug.cgi?id=17093
llvm-svn: 189972

llvm-svn: 189971

No functionality change.

llvm-svn: 189969

llvm-svn: 189967

Unaligned vldm/vstm need more uops and therefore are slower in general on swift.

radar://14522102

llvm-svn: 189961

Fix scheduling for vldm/vstm instructions that load/store more than 32 bytes on Cortex-A9. This also makes the existing code more compact.

llvm-svn: 189958

This reverts commit r189886.

I found a corner case where this optimization is not valid:

Say we have a "linkonce_odr unnamed_addr" in two translation units:
* In TU 1 this optimization kicks in and makes it hidden.
* In TU 2 it gets const merged with a constant that is *not* unnamed_addr,
  resulting in a non unnamed_addr constant with default visibility.
* The static linker rules for combining visibility them produce a hidden
  symbol, which is incorrect from the point of view of the non unnamed_addr
  constant.

The one place we can do this is when we know that the symbol is not used from
another TU in the same shared object, i.e., during LTO. I will move it there.

llvm-svn: 189954

Move generic isPrint and columnWidth implementations to a separate header/source to allow using both generic and system-dependent versions on win32.

Summary:
This is needed so we can use generic columnWidthUTF8 in clang-format on
win32 simultaneously with a separate system-dependent implementations of
isPrint/columnWidth in TextDiagnostic.cpp to avoid attempts to print Unicode
characters using narrow-character interfaces (which is not supported on Windows,
and we'll have to figure out how to handle this).

Reviewers: jordan_rose

Reviewed By: jordan_rose

CC: llvm-commits, klimek

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

llvm-svn: 189952

llvm-svn: 189950

  This assertion is triggered because an integer constant is created with wrong
  type.

llvm-svn: 189948

llvm-svn: 189945

llvm-svn: 189940

MemoryBuffer.cpp: Don't peek the next page if file is multiple of *physical* pagesize(4k) but is not multiple of AllocationGranularity(64k), when a null terminator is required, on cygwin and win32.

For example, r189780's SparcISelLowering.cpp has the size 98304. It crashed clang to touch a null terminator on cygwin.

FIXME: It's not good to hardcode 4096 here. dwPageSize shows 4096.
llvm-svn: 189939

llvm-svn: 189938

This was regression from r134829. When linking we have to be conservative. If
one of the symbols has a significant address, then the result should have it
too.

llvm-svn: 189935

"(icmp op i8 A, B)" is equivalent to "(icmp op i8 (A & 0xff), B)" as a
degenerate case. Allowing this as a "masked" comparison when analysing "(icmp)
&/| (icmp)" allows us to combine them in more cases.

rdar://problem/7625728

llvm-svn: 189931

Even in cases which aren't universally optimisable like "(A & B) != 0 && (A &
C) != 0", the masks can make one of the comparisons completely redundant. In
this case, since we've gone to the effort of spotting masked comparisons we
should combine them.

rdar://problem/7625728

llvm-svn: 189930

      sshr,ushr,ssra,usra,srshr,urshr,srsra,ursra,sri,shl,sli,sqshlu,sqshl,uqshl,shrn,sqrshrun,sqshrn,uqshr,sqrshrn,uqrshrn,sshll,ushll
 and 4 convert instructions:
      scvtf,ucvtf,fcvtzs,fcvtzu

llvm-svn: 189925

Revert "Revert "Remove the darwin gdb option, that version of gdb is now dead and the rest of the compatibility should be done on a dwarf-N level.""

This reverts commit r189913.

Talked with Eric on IRC. I am going to XFAIL the failing test since it
is using what Eric described as "the member hack" which was needed on
that old GDB.

Sorry for the noise!

llvm-svn: 189914

Revert "Remove the darwin gdb option, that version of gdb is now dead and the rest of the compatibility should be done on a dwarf-N level."

This reverts commit r189903.

This commit broke the phase 1 buildbot for a while.

http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-nobootstrap-RAincremental/builds/6684

llvm-svn: 189913

llvm-svn: 189912

Iterator of std::vector may be implemented as a raw pointer. In
this case begin iterators are rvalues and cannot be incremented.
For example, this is the case with STDCXX implementation of vector.

Patch by Konstantin Tokarev <annulen@yandex.ru>.

llvm-svn: 189911

the rest of the compatibility should be done on a dwarf-N level.

llvm-svn: 189903