No functionality change.

llvm-svn: 186470

llvm-svn: 186466

SLPVectorizer: Improve the compile time of isConsecutive by adding a simple constant-gep check before using SCEV.
This check does not always work because not all of the GEPs use a constant offset, but it happens often enough to reduce the number of times we use SCEV.

llvm-svn: 186465

block. Blocks that have an indirect branch terminator, even if it's not the
last terminator, should still be treated as unanalyzable.

<rdar://problem/14437274>

Reducing a useful regression test case is proving difficult - I hope to have
one soon.

llvm-svn: 186461

This adds an instruction alias to make the assembler recognize the alternate literal form: pli [PC, #+/-<imm>]

See A8.8.129 in the ARM ARM (DDI 0406C.b).

Fixes <rdar://problem/14403733>.

llvm-svn: 186459

This centralizes the handling of O_BINARY and opens the way for hiding more
differences (like how open behaves with directories).

llvm-svn: 186447

These floats all represented block frequencies anyway, so just use the
BlockFrequency class directly.

Some floating point computations remain in tryLocalSplit(). They are
estimating spill weights which are still floats.

llvm-svn: 186435

Original commit message:

Remove floating point computations from SpillPlacement.cpp.

Patch by Benjamin Kramer!

Use the BlockFrequency class instead of floats in the Hopfield network
computations. This rescales the node Bias field from a [-2;2] float
range to two block frequencies BiasN and BiasP pulling in opposite
directions. This construct has a more predictable behavior when block
frequencies saturate.

The per-node scaling factors are no longer necessary, assuming the block
frequencies around a bundle are consistent.

This patch can cause the register allocator to make different spilling
decisions. The differences should be small.

llvm-svn: 186434

Use PMIN/PMAX for UGE/ULE vector comparions to reduce the number of required
instructions. This trick also works for UGT/ULT, but there is no advantage in
doing so. It wouldn't reduce the number of instructions and it would actually
reduce performance.

Reviewer: Ben

radar:5972691

llvm-svn: 186432

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

llvm-svn: 186431

llvm-svn: 186429

This is to support parsing UTF16 response files in LLVM/lib/Option for
lld and clang.

Reviewers: hans

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

llvm-svn: 186426

For safety, the inliner cannot decrease the allignment on an alloca when
merging it with another.

I've included two variants of the test case for this: one with DataLayout
available, and one without. When DataLayout is not available, if only one of
the allocas uses the default alignment (getAlignment() == 0), then they cannot
be safely merged.

llvm-svn: 186425

Process groups of stores in chunks of 16.

llvm-svn: 186420

llvm-svn: 186414

llvm-svn: 186413

[APFloat] PR16573: Avoid losing mantissa bits in ppc_fp128 to double truncation

When truncating to a format with fewer mantissa bits, APFloat::convert
will perform a right shift of the mantissa by the difference of the
precision of the two formats.  Usually, this will result in just the
mantissa bits needed for the target format.

One special situation is if the input number is denormal.  In this case,
the right shift may discard significant bits.  This is usually not a
problem, since truncating a denormal usually results in zero (underflow)
after normalization anyway, since the result format's exponent range is
usually smaller than the target format's.

However, there is one case where the latter property does not hold:
when truncating from ppc_fp128 to double.  In particular, truncating
a ppc_fp128 whose first double of the pair is denormal should result
in just that first double, not zero.  The current code however
performs an excessive right shift, resulting in lost result bits.
This is then caught in the APFloat::normalize call performed by
APFloat::convert and causes an assertion failure.

This patch checks for the scenario of truncating a denormal, and
attempts to (possibly partially) replace the initial mantissa
right shift by decrementing the exponent, if doing so will still
result in a valid *target format* exponent.


Index: test/CodeGen/PowerPC/pr16573.ll
===================================================================
--- test/CodeGen/PowerPC/pr16573.ll	(revision 0)
+++ test/CodeGen/PowerPC/pr16573.ll	(revision 0)
@@ -0,0 +1,11 @@
+; RUN: llc < %s | FileCheck %s
+
+target triple = "powerpc64-unknown-linux-gnu"
+
+define double @test() {
+  %1 = fptrunc ppc_fp128 0xM818F2887B9295809800000000032D000 to double
+  ret double %1
+}
+
+; CHECK: .quad -9111018957755033591
+
Index: lib/Support/APFloat.cpp
===================================================================
--- lib/Support/APFloat.cpp	(revision 185817)
+++ lib/Support/APFloat.cpp	(working copy)
@@ -1956,6 +1956,23 @@
     X86SpecialNan = true;
   }
 
+  // If this is a truncation of a denormal number, and the target semantics
+  // has larger exponent range than the source semantics (this can happen
+  // when truncating from PowerPC double-double to double format), the
+  // right shift could lose result mantissa bits.  Adjust exponent instead
+  // of performing excessive shift.
+  if (shift < 0 && isFiniteNonZero()) {
+    int exponentChange = significandMSB() + 1 - fromSemantics.precision;
+    if (exponent + exponentChange < toSemantics.minExponent)
+      exponentChange = toSemantics.minExponent - exponent;
+    if (exponentChange < shift)
+      exponentChange = shift;
+    if (exponentChange < 0) {
+      shift -= exponentChange;
+      exponent += exponentChange;
+    }
+  }
+
   // If this is a truncation, perform the shift before we narrow the storage.
   if (shift < 0 && (isFiniteNonZero() || category==fcNaN))
     lostFraction = shiftRight(significandParts(), oldPartCount, -shift);

llvm-svn: 186409

Previously an asm operand with no operand modifier would give the error
"invalid operand in inline asm".

llvm-svn: 186407

We'd forgotten to provide string representations for the special ARMISD atomic
nodes; this adds them in. No effect on CodeGen, just makes the output of
"-view-whatever-dags" slightly more readable.

llvm-svn: 186406

llvm-svn: 186405

llvm-svn: 186403

CodeGen support will come later.

llvm-svn: 186401

Another patch in the series to make more use of R.SBG.  This one extends
r186072 and r186073 to handle cases where the AND is inside the shift.

llvm-svn: 186399

 This patch represents Mips utilization of r186388 code that alows asm matcher to emit mnemonics contain '.' characters. This makes asm parser code simpler and more efficient.

llvm-svn: 186397

    g++ (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10)

llvm-svn: 186396

Intrinsics already existed for the 64-bit variants, so these support operations
of size at most 32-bits.

llvm-svn: 186392

This patch enables calls to __aeabi_idivmod when in EABI mode,
by using the remainder value returned on registers (R1),
enabled by the ARM triple "none-eabi". Note that Darwin and
GNUEABI triples will continue lowering on GNU style, that is,
using the stack for the remainder.

Still need to add SREM/UREM support fix for 64-bit lowering.

llvm-svn: 186390

llvm-svn: 186378

This opens the way of having static helpers in the .inc files that can
construct a file_status.

llvm-svn: 186376

llvm-svn: 186371

We can have a FrameSetup in one basic block and the matching FrameDestroy
in a different basic block when we have struct byval. In that case, SPAdj
is not zero at beginning of the basic block.

Modify PEI to correctly set SPAdj at beginning of each basic block using
DFS traversal. We used to assume SPAdj is 0 at beginning of each basic block.

PEI had an assert SPAdjCount || SPAdj == 0.
If we have a Destroy <n> followed by a Setup <m>, PEI will assert failure.
We can add an extra condition to make sure the pairs are matched:
  The pairs start with a FrameSetup.
But since we are doing a much better job in the verifier, this patch removes
the check in PEI.

PR16393

llvm-svn: 186364

Compares return i1 but they compare different types.

llvm-svn: 186359

This change mirrors the changes that were made to the X86 and ARM targets to
support subtarget feature changing. As indicated in r182899, the mechanism is
still undergoing revision, and so as with the X86 and ARM targets, there is no
test case yet (there is no effective functionality change).

llvm-svn: 186357

1> on every path through the CFG, a FrameSetup <n> is always followed by a
   FrameDestroy <n> and a FrameDestroy is always followed by a FrameSetup.
2> stack adjustments are identical on all CFG edges to a merge point.
3> frame is destroyed at end of a return block.

PR16393

llvm-svn: 186350

I checked that opening a directory on windows does fail, so this saves a "stat".

llvm-svn: 186345

PPCInstrInfo::insertSelect and PPCInstrInfo::canInsertSelect were computing the
common subclass of the true and false inputs, and then selecting either the
32-bit or the 64-bit isel variant based on the result of calling
PPC::GPRCRegClass.hasSubClassEq(RC) and PPC::G8RCRegClass.hasSubClassEq(RC)
(where RC is the common subclass). Unfortunately, this is not quite right: if
we have something like this:

  %vreg8<def> = SELECT_CC_I8 %vreg4<kill>, %vreg7<kill>, %vreg6<kill>, 76;
    G8RC_and_G8RC_NOX0:%vreg8 CRRC:%vreg4 G8RC_NOX0:%vreg7,%vreg6

then the common subclass of G8RC_and_G8RC_NOX0 and G8RC_NOX0 is G8RC_NOX0, and
G8RC_NOX0 is not a subclass of G8RC (because it also contains the ZERO8
pseudo-register). As a result, we also need to check the common subclass
against GPRC_NOR0 and G8RC_NOX0 explicitly.

This had not been a problem for clients of insertSelect that called
canInsertSelect first (because it had a compensating mistake), but insertSelect
is also used by the PPC pseudo-instruction expander, and this error was causing
a problem in that context.

This problem was found by csmith.

llvm-svn: 186343

This is consistent with the ELF object writer.

Add some COFF tests that relocate against an alias.

Reviewers: espindola

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

llvm-svn: 186341

https://bugs.freedesktop.org/show_bug.cgi?id=65873

llvm-svn: 186339

There is a comment at the top of DAGTypeLegalizer::PerformExpensiveChecks
which, in part, says:

  // Note that these invariants may not hold momentarily when processing a node:
  // the node being processed may be put in a map before being marked Processed.

Unfortunately, this assert would be valid only if the above-mentioned invariant
held unconditionally. This was causing llc to assert when, in fact,
everything was fine.

Thanks to Richard Sandiford for investigating this issue!

Fixes PR16562.

llvm-svn: 186338

llvm-svn: 186333