Re-instate the pragma optimize hack for MSVC, but not clang-cl

Reverts commit r230686 with define modifications.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230692 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Restructure the comments and the conditions for handling
dynamic blends.

This makes it much more clear what is going on. The case we're handling
is that of dynamic conditions, and we're bailing when the nature of the
vector types and subtarget preclude lowering the dynamic condition
vselect as an actual blend.

No functionality changed here, but this will make a subsequent bug-fix
to this code much more clear.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230690 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Re-order the combines of select in the X86 backend. This doesn't
change functionality, but makes it more clear that the dynamic case and
the shuffle case don't overlap in any interesting way.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230689 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Add an assert to catch if we ever try to blend a v32i8 without
AVX2.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230688 91177308-0d34-0410-b5e6-96231b3b80d8

Remove stale pragma hack for an unsupported MSVC version

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230686 91177308-0d34-0410-b5e6-96231b3b80d8

Silence some Win64 clang-cl warnings about unused stuff due to ifdefs

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230685 91177308-0d34-0410-b5e6-96231b3b80d8

Use wider type for overflow check on LLP64 platforms like Win64, found by clang-cl -Wtautological

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230684 91177308-0d34-0410-b5e6-96231b3b80d8

IRCE: add a test case for r230619.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230680 91177308-0d34-0410-b5e6-96231b3b80d8

InstrProf: Simplify the construction of BinaryCoverageReader

Creating BinaryCoverageReader is a strange and complicated dance where
the constructor sets error codes that member functions will later
read, and the object is in an invalid state if readHeader isn't
immediately called after construction.

Instead, make the constructor private and add a static create method
to do the construction properly. This also has the benefit of removing
readHeader completely and simplifying the interface of the object.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230676 91177308-0d34-0410-b5e6-96231b3b80d8

InstrProf: Rename ObjectFileCoverageMappingReader to BinaryCoverageReader

The current name is long and confusing. A shorter one is both easier
to understand and easier to work with.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230675 91177308-0d34-0410-b5e6-96231b3b80d8

SCEVExpander incorrectly marks generated subtractions as nuw/nsw

It is not sound to mark the increment operation as `nuw` or `nsw`
based on a proof off of the add recurrence if the increment operation
we emit happens to be a `sub` instruction.

I could not come up with a test case for this -- the cases where
SCEVExpander decides to emit a `sub` instruction is quite small, and I
cannot think of a way I'd be able to get SCEV to prove that the
increment does not overflow in those cases.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230673 91177308-0d34-0410-b5e6-96231b3b80d8

Try to fix a docs link.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230672 91177308-0d34-0410-b5e6-96231b3b80d8

[MC] Use the non-EH register mapping in the debug_frame section.

On 32bits x86 Darwin, the register mappings for the eh_frane and
debug_frame sections are different. Thus the same CFI instructions
should result in different registers in the object file. The
problem isn't target specific though, but it requires that the
mappings for EH register numbers be different from the standard
Dwarf one.

The patch looks a bit clumsy. LLVM uses the EH mapping as
canonical for everything frame related. Thus we need to do a
double conversion EH -> LLVM -> Non-EH, when emitting the
debug_frame section.

Fixes PR22363.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230670 91177308-0d34-0410-b5e6-96231b3b80d8

Support bitrig in autoconf build system.

Patch by Dave Huseby.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230669 91177308-0d34-0410-b5e6-96231b3b80d8

Don't sibcall between SysV and Win64 convention functions

The shadow stack space expectations won't match.

Fixes PR22709.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230667 91177308-0d34-0410-b5e6-96231b3b80d8

[Orc][Kaleidoscope] Fix a missed symbol mangling operation in the fully lazy tutorial.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230664 91177308-0d34-0410-b5e6-96231b3b80d8

[InstCombine/PowerPC] Convert aligned QPX load/store intrinsics into loads/stores

InstCombine has long had logic to convert aligned Altivec load/store intrinsics
into regular loads and stores. This mirrors that functionality for QPX vector
load/store intrinsics.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230660 91177308-0d34-0410-b5e6-96231b3b80d8

When the source has a series of assignments, users reasonably want to
have the debugger step through each one individually. Turn off the
combine for adjacent stores at -O0 so we get this behavior.

Possibly, DAGCombine shouldn't run at all at -O0, but that's for
another day; see PR22346.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230659 91177308-0d34-0410-b5e6-96231b3b80d8

[Orc][Kaleidoscope] More diff-reduction between tutorial versions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230658 91177308-0d34-0410-b5e6-96231b3b80d8

Fix justify error for small structures in varargs for MIPS64BE

There was a problem when passing structures as variable arguments.
The structures smaller than 64 bit were not left justified on MIPS64
big endian. This is now fixed by shifting the value to make it left-
justified when appropriate.

This fixes the bug http://llvm.org/bugs/show_bug.cgi?id=21608

Patch by Aleksandar Beserminji.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230657 91177308-0d34-0410-b5e6-96231b3b80d8

gold-plugin: "Upgrade" debug info and handle its warnings.

The gold plugin never calls MaterializeModule, so any old debug info
was not deleted and could cause crashes.

Now that it is being "upgraded", the plugin also has to handle warnings
and create Modules with a nice id (it shows in the warning).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230655 91177308-0d34-0410-b5e6-96231b3b80d8

Use ".arch_extension" ARM directive to support hwdiv on krait

In case of "krait" CPU, asm printer doesn't emit any ".cpu" so the
features bits are not computed. This patch lets the asm printer
emit ".cpu cortex-a9" directive for krait and the hwdiv feature is
enabled through ".arch_extension". In short, krait is treated
as "cortex-a9" with hwdiv. We can not emit ".krait" as CPU since
it is not supported bu GNU GAS yet

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230651 91177308-0d34-0410-b5e6-96231b3b80d8

Use ".arch_extension" ARM directive to specify the additional CPU features

This patch is in response to r223147 where the avaiable features are
computed based on ".cpu" directive. This will work clean for the standard
variants like cortex-a9. For custom variants which rely on standard cpu names
for assembly, the additional features of a CPU should be propagated. This can be
done via ".arch_extension" as long as the assembler supports it. The
implementation for krait along with unit test will be submitted in next patch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230650 91177308-0d34-0410-b5e6-96231b3b80d8

[LV/LoopAccesses] Backward dependences are not safe just because the
accesses are via different types

Noticed this while generalizing the code for loop distribution.

I confirmed with Arnold that this was indeed a bug and managed to create
a testcase.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230647 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Remove M0 from DS assembly strings

This matches the assembly syntax for the proprietary compiler.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230645 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][MMX] Fix a typo in a couple of tests

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230638 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][MMX] Remove widening experimental flag from MMX tests.

Turns out that after the past MMX commits, we don't need to rely on this
flag to get better codegen for MMX. Also update the tests to become
triple neutral.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230637 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][Haswell][SchedModel] Fix WriteMULm latency.

The latency for the WriteMULm class was set to 4, which is actually lower than the latency for WriteMULr (5).
A better estimate would be 4 added to WriteMULr, that is, 9.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230634 91177308-0d34-0410-b5e6-96231b3b80d8

[InstCombine] Add a test for altivec load/store intrinsic simplification

InstCombine has logic to convert aligned Altivec load/store intrinsics into
regular loads and stores. Unfortunately, there seems to be no regression test
covering this behavior. Adding one...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230632 91177308-0d34-0410-b5e6-96231b3b80d8

Replace obsolete -mattr=n64 command line option with -target-abi=n64. No functional changes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230628 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Sink the single-input v8i16 lowering code that is actually
formulaic into the top v8i16 lowering routine.

This makes the generalized lowering a completely general and single path
lowering which will allow generalizing it in turn for multiple 128-bit
lanes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230623 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Remove a SimpleTy usage. No need for it here, we already have the
MVT.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230622 91177308-0d34-0410-b5e6-96231b3b80d8

IRCE: only touch loops that have been shown to have a high
backedge-taken count in profiliing data.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230619 91177308-0d34-0410-b5e6-96231b3b80d8

IRCE: generalize to handle loops with decreasing induction variables.

IRCE can now split the iteration space for loops like:

   for (i = n; i >= 0; i--)
     a[i + k] = 42; // bounds check on access

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230618 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Make the vector shuffle helpers order the SDLoc and MVT arguments.
This ordering matches that of DAG.getNode.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230617 91177308-0d34-0410-b5e6-96231b3b80d8

IR: Use '= default' instead of r230609, NFC

Apparently we can use this now!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230613 91177308-0d34-0410-b5e6-96231b3b80d8

FileCheck: Add CHECK-SAME

Add `CHECK-SAME`, which requires that the pattern matches on the *same*
line as the previous `CHECK`/`CHECK-NEXT` -- in other words, no newline
is allowed in the skipped region.  This is similar to `CHECK-NEXT`,
which requires exactly 1 newline in the skipped region.

My motivation is to simplify checking the long lines of LLVM assembly
for the new debug info hierarchy.  This allows CHECK sequences like the
following:

    CHECK:      ![[REF]] = !SomeMDNode(
    CHECK-SAME: file: ![[FILE:[0-9]+]]
    CHECK-SAME: otherField: 93{{[,)]}}

which is equivalent to:

    CHECK: ![[REF]] = !SomeMDNode({{.*}}file: ![[FILE:[0-9]+]]{{.*}}otherField: 93{{[,)]}}

While this example just has two fields, many nodes in debug info have
more than that.  `CHECK-SAME` will keep the logic easy to follow.

Morever, it enables interleaving `CHECK-NOT`s without allowing newlines.
Consider the following:

    CHECK:      ![[REF]] = !SomeMDNode(
    CHECK-SAME: file: ![[FILE:[0-9]+]]
    CHECK-NOT:  unexpectedField:
    CHECK-SAME: otherField: 93{{[,)]}}
    CHECK-NOT:  otherUnexpectedField:
    CHECK-SAME: )

which doesn't seem to have an equivalent `CHECK` line.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230612 91177308-0d34-0410-b5e6-96231b3b80d8

IR: Add default constructor for DIImportedEntity

Add a default constructor for `DIImportedEntity`, to be used in clang in
a follow-up.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230609 91177308-0d34-0410-b5e6-96231b3b80d8

[LoopAccesses] Add command-line option for RuntimeMemoryCheckThreshold

Also remove the somewhat misleading initializers from
VectorizationFactor and VectorizationInterleave.  They will get
initialized with the default ctor since no cl::init is provided.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230608 91177308-0d34-0410-b5e6-96231b3b80d8

IRCE: print newline after printing an InductiveRangeCheck.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230607 91177308-0d34-0410-b5e6-96231b3b80d8

[GC docs] Add example IR, assembly, and stackmaps to Statepoint documentation

When I originally committed the statepoint docs, I left placeholders for example IR fragments.  I'm finally getting around to filling those in.

I also added IR fragments to illustrate the usage of the PlaceSafepoints pass while I was at it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230601 91177308-0d34-0410-b5e6-96231b3b80d8

Replace a few instances of NULL with nullptr.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230599 91177308-0d34-0410-b5e6-96231b3b80d8

Pass /nologo to ml64 for quieter builds

It still prints "Assembling path/to/X86CompilationCallback_Win64.asm",
but linking does the same thing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230596 91177308-0d34-0410-b5e6-96231b3b80d8

PlaceSafepoints: use IRBuilder helpers

Use the IRBuilder helpers for gc.statepoint and gc.result, instead of
coding the construction by hand. Note that the gc.statepoint IRBuilder
handles only CallInst, not InvokeInst; retain that part of hand-coding.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230591 91177308-0d34-0410-b5e6-96231b3b80d8

Remove a FIXME.

Explanation: This function is in TargetLowering because it uses
RegClassForVT which would need to be moved to TargetRegisterInfo
and would necessitate moving isTypeLegal over as well - a massive
change that would just require TargetLowering having a TargetRegisterInfo
class member that it would use.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230585 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a couple of depedent->dependent typos.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230584 91177308-0d34-0410-b5e6-96231b3b80d8

Remove an argument-less call to getSubtargetImpl from TargetLoweringBase.
This required plumbing a TargetRegisterInfo through computeRegisterProperties
and into findRepresentativeClass which uses it for register class
iteration. This required passing a subtarget into a few target specific
initializations of TargetLowering.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230583 91177308-0d34-0410-b5e6-96231b3b80d8

MemDepPrinter: Fix some nits introduced in r228596

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230582 91177308-0d34-0410-b5e6-96231b3b80d8

[GC docs] More minor word tweaks to make the GC bits clearer

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230581 91177308-0d34-0410-b5e6-96231b3b80d8

[GC Docs] Update LangRef to link to Statepoint docs

Add a brief section linking to the experimental statepoint intrinsics analogous to the one we have linking to patchpoint.

While I'm here, cleanup some wording about what the gc "name" attribute actually means.  It's not the name of a *collector* it's the name of the *strategy* which may be compatible with multiple collectors.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230576 91177308-0d34-0410-b5e6-96231b3b80d8

[GC docs] Fill in description of the statepoint-example GC strategy

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230572 91177308-0d34-0410-b5e6-96231b3b80d8

[GC Docs] Minor wording clarification

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230570 91177308-0d34-0410-b5e6-96231b3b80d8

Object: Handle Mach-O kext bundle files

This particular subtype of Mach-O was missing. Add it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230567 91177308-0d34-0410-b5e6-96231b3b80d8

InstrProf: Make the __llvm_profile_runtime_user symbol hidden

This symbol exists only to pull in the required pieces of the runtime,
so nothing ever needs to refer to it. Making it hidden avoids the
potential for issues with duplicate symbols when linking profiled
libraries together.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230566 91177308-0d34-0410-b5e6-96231b3b80d8

IR: Drop newline from AssemblyWriter::printMDNodeBody()

Remove a newline from `AssemblyWriter::printMDNodeBody()`, and add one
to `AssemblyWriter::writeMDNode()`.  NFCI for assembly output.

However, this drops an inconsistent newline from `Metadata::print()`
when `this` is an `MDNode`.  Now the newline added by `Metadata::dump()`
won't look so verbose.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230565 91177308-0d34-0410-b5e6-96231b3b80d8

only propagate equality comparisons of FP values that we are certain are non-zero

This is a follow-on to r227491 which tightens the check for propagating FP
values. If a non-constant value happens to be a zero, we would hit the same
bug as before.

Bug noted and patch suggested by Eli Friedman.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230564 91177308-0d34-0410-b5e6-96231b3b80d8

InstrProf: Remove dead code in CoverageMappingReader

Remove a default argument that's never passed and a constructor that's
never called.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230563 91177308-0d34-0410-b5e6-96231b3b80d8

Move TargetLoweringBase::getTypeConversion to the .cpp file from
the .h file. It's used in only one place (other than recursively)
and there's no need to include it everywhere.

Saves almost 900k from total llvm object file size.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230561 91177308-0d34-0410-b5e6-96231b3b80d8

InstCombine: extract instead of shuffle when performing vector/array type punning

Summary: SROA generates code that isn't quite as easy to optimize and contains unusual-sized shuffles, but that code is generally correct. As discussed in D7487 the right place to clean things up is InstCombine, which will pick up the type-punning pattern and transform it into a more obvious bitcast+extractelement, while leaving the other patterns SROA encounters as-is.

Test Plan: make check

Reviewers: jvoung, chandlerc

Subscribers: llvm-commits

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230560 91177308-0d34-0410-b5e6-96231b3b80d8

[dwarfdump] Fix frame info register number dump.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230559 91177308-0d34-0410-b5e6-96231b3b80d8

IR: Annotate dump methods with LLVM_DUMP_METHOD

It turns out we have a macro to ensure that debuggers can access
`dump()` methods.  Use it.  Hopefully this will prevent me (and others)
from committing crimes like in r223802 (search for /10000/, or just see
the fix in r224407).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230555 91177308-0d34-0410-b5e6-96231b3b80d8

Try to appease buildbots.

It seems ArrayRefs to multi-dimensional arrays confuse some compilers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230554 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Make LDtocL and friends invariant loads

LDtocL, and other loads that roughly correspond to the TOC_ENTRY SDAG node,
represent loads from the TOC, which is invariant. As a result, these loads can
be hoisted out of loops, etc. In order to do this, we need to generate
GOT-style MMOs for TOC_ENTRY, which requires treating it as a legitimate memory
intrinsic node type. Once this is done, the MMO transfer is automatically
handled for TableGen-driven instruction selection, and for nodes generated
directly in PPCISelDAGToDAG, we need to transfer the MMOs manually.

Also, we were not transferring MMOs associated with pre-increment loads, so do
that too.

Lastly, this fixes an exposed bug where R30 was not added as a defined operand of
UpdateGBR.

This problem was highlighted by an example (used to generate the test case)
posted to llvmdev by Francois Pichet.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230553 91177308-0d34-0410-b5e6-96231b3b80d8

[dwarfdump] Make debug_frame dump actually useful.

This adds support for pretty-printing instruction operands. The new
output looks like:

00000000 00000010 ffffffff CIE
  Version:               1
  Augmentation:
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 8

  DW_CFA_def_cfa:  reg4 +4
  DW_CFA_offset:  reg8 -4
  DW_CFA_nop:
  DW_CFA_nop:

00000014 00000010 00000000 FDE cie=00000000 pc=00000000...00000022
  DW_CFA_advance_loc:  3
  DW_CFA_def_cfa_offset:  +12
  DW_CFA_nop:

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230551 91177308-0d34-0410-b5e6-96231b3b80d8

[dwarfdump] Don't print meaningless pointer.

CIE pointers were never filled in before, and printing the pointer
is totally pointless anyway.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230550 91177308-0d34-0410-b5e6-96231b3b80d8

DWARFDebugFrame: Move some code around. NFC.

Move the FrameEntry::dumpInstructions down in the file at some
place where it can see the declarations of FDE and CIE.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230549 91177308-0d34-0410-b5e6-96231b3b80d8

DWARFDebugFrame: Add some trivial accessors. NFC.

To be used for dumping.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230548 91177308-0d34-0410-b5e6-96231b3b80d8

DWARFDebugFrame: Actually collect CIEs associated with FDEs.

This is the first commit in a small series aiming at making
debug_frame dump more useful (right now it prints a list of
opeartions without their operands).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230547 91177308-0d34-0410-b5e6-96231b3b80d8

[LTO API] fix memory leakage introduced at r230290.

r230290 released the LLVM module but not the LTOModule.

rdar://19024554

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230544 91177308-0d34-0410-b5e6-96231b3b80d8

X86, Win64: Allow 'mov' to restore the stack pointer if we have a FP

The Win64 epilogue structure is very restrictive, it permits a very
small number of opcodes and none of them are 'mov'.

This means that given:
  mov %rbp, %rsp
  pop %rbp

The mov isn't the epilogue, only the pop is.  This is problematic unless
a frame pointer is present in which case we are free to do whatever we'd
like in the "body" of the function.  If a frame pointer is present,
unwinding will undo the prologue operations in reverse order regardless
of the fact that we are at an instruction which is reseting the stack
pointer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230543 91177308-0d34-0410-b5e6-96231b3b80d8

[Orc][Kaleidoscope] Clean up the Orc/Kaleidoscope tutorials to minimize the diffs
between them.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230542 91177308-0d34-0410-b5e6-96231b3b80d8

LowerBitSets: Align referenced globals.

This change aligns globals to the next highest power of 2 bytes, up to a
maximum of 128. This makes it more likely that we will be able to compress
bit sets with a greater alignment. In many more cases, we can now take
advantage of a new optimization also introduced in this patch that removes
bit set checks if the bit set is all ones.

The 128 byte maximum was found to provide the best tradeoff between instruction
overhead and data overhead in a recent build of Chromium. It allows us to
remove ~2.4MB of instructions at the cost of ~250KB of data.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230540 91177308-0d34-0410-b5e6-96231b3b80d8

[CMake] Fix the clang-cl self host build.

This allows clang-cl to self-host cleanly with no magic setup
steps required.

After this patch, all you have to do is set CC=CXX=clang-cl and
run cmake -G Ninja.

These changes only exist to support C++ features which are
unsupported in clang-cl, so regardless of whether the user
specifies they want to use them, we still have to disable them.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230539 91177308-0d34-0410-b5e6-96231b3b80d8

Fixing a problem with insert location in WinEH outlining

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230535 91177308-0d34-0410-b5e6-96231b3b80d8

Bugfix: SCEVExpander incorrectly marks increment operations as no-wrap

(The change was landed in r230280 and caused the regression PR22674.
This version contains a fix and a test-case for PR22674).

When emitting the increment operation, SCEVExpander marks the
operation as nuw or nsw based on the flags on the preincrement SCEV.
This is incorrect because, for instance, it is possible that {-6,+,1}
is <nuw> while {-6,+,1}+1 = {-5,+,1} is not.

This change teaches SCEV to mark the increment as nuw/nsw only if it
can explicitly prove that the increment operation won't overflow.

Apart from the attached test case, another (more realistic)
manifestation of the bug can be seen in
Transforms/IndVarSimplify/pr20680.ll.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230533 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Cleanup unused target-specific SDAG nodes

We had somehow accumulated a few target-specific SDAG nodes dealing with PPC64
TOC access that were referenced only in TableGen patterns. The associated
(pseudo-)instructions are used, but are being generated directly. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230518 91177308-0d34-0410-b5e6-96231b3b80d8

AArch64: Add debug message for large shift constants.

As requested in code review.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230517 91177308-0d34-0410-b5e6-96231b3b80d8

Fix really obscure bug in CannotBeNegativeZero() (PR22688)

With a diabolically crafted test case, we could recurse
through this code and return true instead of false.

The larger engineering crime is the use of magic numbers.
Added FIXME comments for those.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230515 91177308-0d34-0410-b5e6-96231b3b80d8

fix a typo

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230510 91177308-0d34-0410-b5e6-96231b3b80d8

[MIPS]Multiple and add instructions for Mips are currently available in mips32r2/mips64r2 and later but should also be available in mips4, mips5, and mips64. This patch fixes the requested features and updates the corresponding test files.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230500 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][MMX] Reapply: Add MMX instructions to foldable tables

Reapply r230248.

Teach the peephole optimizer to work with MMX instructions by adding
entries into the foldable tables. This covers folding opportunities not
handled during isel.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230499 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][MMX] Prevent MMX_MOVD64rm folding

MMX_MOVD64rm zero-extends i32 load results into i64 registers.

The peephole optimizer will try to fold it in other MMX foldable
instructions, the wrong thing to do, since there's no MMX memory
instruction that loads from i32 and does implict zero extension.

Remove 'canFoldAsLoad' from MOVD64rm in order to prevent such folding.
The current MMX tests already test this, but since there are no MMX
instructions in the foldable tables yet, this did not trigger. This
commit prepares the addition of those instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230498 91177308-0d34-0410-b5e6-96231b3b80d8

Improve handling of stack accesses in Thumb-1

Thumb-1 only allows SP-based LDR and STR to be word-sized, and SP-base LDR,
STR, and ADD only allow offsets that are a multiple of 4. Make some changes
to better make use of these instructions:

* Use word loads for anyext byte and halfword loads from the stack.
* Enforce 4-byte alignment on objects accessed in this way, to ensure that
  the offset is valid.
* Do the same for objects whose frame index is used, in order to avoid having
  to use more than one ADD to generate the frame index.
* Correct how many bits of offset we think AddrModeT1_s has.

Patch by John Brawn.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230496 91177308-0d34-0410-b5e6-96231b3b80d8

Silencing a "result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)" warning in MSVC; NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230489 91177308-0d34-0410-b5e6-96231b3b80d8

Silencing a -Wsign-compare warning triggered in MSVC; NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230488 91177308-0d34-0410-b5e6-96231b3b80d8

Replace obsolete -mattr=n64 command line option with -target-abi=n64. No functional changes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230482 91177308-0d34-0410-b5e6-96231b3b80d8

GlobalLayoutBuilder::addFragment(): Prune incorrect usage of \param(s). [-Wdocumentation]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230480 91177308-0d34-0410-b5e6-96231b3b80d8

Fix UTF8 chars to ASCII.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230479 91177308-0d34-0410-b5e6-96231b3b80d8

AVX-512: Gather and Scatter patterns
Gather and scatter instructions additionally write to one of the source operands - mask register.
In this case Gather has 2 destination values - the loaded value and the mask.
Till now we did not support code gen pattern for gather - the instruction was generated from
intrinsic only and machine node was hardcoded.
When we introduce the masked_gather node, we need to select instruction automatically,
in the standard way.
I added a flag "hasTwoExplicitDefs" that allows to handle 2 destination operands.

(Some code in the X86InstrFragmentsSIMD.td is commented out, just to split one big
patch in many small patches)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230471 91177308-0d34-0410-b5e6-96231b3b80d8

[IC] Turn non-null MD on pointer loads to range MD on integer loads.

Summary:
This change fixes the FIXME that you recently added when you committed
(a modified version of) my patch.  When `InstCombine` combines a load and
store of an pointer to those of an equivalently-sized integer, it currently
drops any `!nonnull` metadata that might be present.  This change replaces
`!nonnull` metadata with `!range !{ 1, -1 }` metadata instead.

Reviewers: chandlerc

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230462 91177308-0d34-0410-b5e6-96231b3b80d8

Add some missing #includes and forward declarations found by modules build.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230457 91177308-0d34-0410-b5e6-96231b3b80d8

build: check if atomic routines are implicitly provided

It is possible for the atomic routines to be provided by the compiler without
requiring any additional libraries.  Check if that is the case before checking
for a library.

Patch by Matt Glazar!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230452 91177308-0d34-0410-b5e6-96231b3b80d8

[modules] Add include/llvm/IR/DebugInfoFlags.def to the textual headers list.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230427 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Add triples to QPX tests

Some of these tests fail on Darwin systems because of a lack of a triple;
fix that.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230421 91177308-0d34-0410-b5e6-96231b3b80d8

[GC] Document the recently added PlaceSafepoints and RewriteGCForStatepoints passes

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230420 91177308-0d34-0410-b5e6-96231b3b80d8

llvm-dis: Stop crashing when dropping debug info

Since r199356, we've printed a warning when dropping debug info.
r225562 started crashing on that, since it registered a diagnostic
handler that only expected errors.  This fixes the handler to expect
other severities.  As a side effect, it now prints "error: " at the
start of error messages, similar to `llvm-as`.

There was a testcase for r199356, but it only really checked the
assembler.  Move `test/Bitcode/drop-debug-info.ll` to `test/Assembler`,
and introduce `test/Bitcode/drop-debug-info.3.5.ll` (and companion
`.bc`) to test the bitcode reader.

Note: tools/gold/gold-plugin.cpp has an equivalent bug, but I'm not sure
what the best fix is there.  I'll file a PR.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230416 91177308-0d34-0410-b5e6-96231b3b80d8

[opaque pointer type] Bitcode support for explicit type parameter on GEP.

Like r230414, add bitcode support including backwards compatibility, for
an explicit type parameter to GEP.

At the suggestion of Duncan I tried coalescing the two older bitcodes into a
single new bitcode, though I did hit a wrinkle: I couldn't figure out how to
create an explicit abbreviation for a record with a variable number of
arguments (the indicies to the gep). This means the discriminator between
inbounds and non-inbounds gep is a full variable-length field I believe? Is my
understanding correct? Is there a way to create such an abbreviation? Should I
just use two bitcodes as before?

Reviewers: dexonsmith

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230415 91177308-0d34-0410-b5e6-96231b3b80d8

[opaque pointer type] bitcode support for explicit type parameter to the load instruction

Summary:
I've taken my best guess at this, but I've cargo culted in places & so
explanations/corrections would be great.

This seems to pass all the tests (check-all, covering clang and llvm) so I
believe that pretty well exercises both the backwards compatibility and common
(same version) compatibility given the number of checked in bitcode files we
already have. Is that a reasonable approach to testing here? Would some more
explicit tests be desired?

1) is this the right way to do back-compat in this case (looking at the number
  of entries in the bitcode record to disambiguate between the old schema and
  the new?)

2) I don't quite understand the logarithm logic to choose the encoding type of
  the type parameter in the abbreviation description, but I found another
  instruction doing the same thing & it seems to work. Is that the right
  approach?

Reviewers: dexonsmith

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230414 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Add support for the QPX vector instruction set

This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially  { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).

I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).

The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230413 91177308-0d34-0410-b5e6-96231b3b80d8

Support SHF_MERGE sections in COMDATs.

This patch unifies the comdat and non-comdat code paths. By doing this
it add missing features to the comdat side and removes the fixed
section assumptions from the non-comdat side.

In ELF there is no one true section for "4 byte mergeable" constants.
We are better off computing the required properties of the section
and asking the context for it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230411 91177308-0d34-0410-b5e6-96231b3b80d8