Fix for PR 26500

This patch corresponds to review:
http://reviews.llvm.org/D17294

It ensures that whatever block we are emitting the prologue/epilogue into, we
have the necessary scratch registers. It takes away the hard-coded register
numbers for use as scratch registers as registers that are guaranteed to be
available in the function prologue/epilogue are not guaranteed to be available
within the function body. Since we shrink-wrap, the prologue/epilogue may end
up in the function body.

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

[X86] Regenerated pr16360.ll

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

[X86][SSE41] More fast-isel intrinsics tests

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

[X86][SSE41] Added fast-isel intrinsics tests

As discussed on PR24580, this patch adds some (more to come) initial fast-isel codegen tests to match the IR generated in clang/test/CodeGen/sse41-builtins.c

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

[DAGCombiner] Use getBitcast helper when possible. NFCI.

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

[X86][SSE] Fixed issue with commutation of 'faux unary' target shuffles (PR26667)

Fixed a bug introduced by D16683 when a binary shuffle is simplified to a unary shuffle (with undef/zero sentinel mask indices) - if this resulted in only the second input being used combineX86ShuffleChain failed to take this into account and still referenced the first input.

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

[X86][SSE] Move all undef/zero cases before target shuffle combining.

First small step towards fixing PR26667 - we need to ensure that combineX86ShuffleChain only gets called with a valid shuffle input node (a similar issue was found in D17041).

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

When MemoryDependenceAnalysis hits a CFG with many transparent blocks,
the algorithm easily degrades into quadratic memory and time complexity.
The easiest example is a long chain of BBs that don't otherwise use a
location. The caching will add an entry for every intermediate block and
limiting the number of results doesn't help as no results are produced
until a definition is found.

Introduce a limit similar to the existing instructions-per-block limit.
This limit counts the total number of blocks checked. If the limit is
reached, entries are considered unknown. The initial value is 1000,
which avoids regressions for normal sized functions while still
limiting edge cases to reasnable memory consumption and execution time.

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

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

[X86] Enable the LEA optimization pass by default.

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

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

[X86] PR26575: Fix LEA optimization pass (Part 2).

Handle address displacement operands of a type other than Immediate or Global in LEAs and load/stores.

Ref: https://llvm.org/bugs/show_bug.cgi?id=26575

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

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

[SimplifyCFG] Use pointer identity to simplify predicate.

No functional change intended.

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

[LVI] Move ConstantRanges instead of copying.

No functional change intended. Copying small (<= 64 bits) APInts isn't
expensive but bloats code by generating the slow path everywhere. Moving
doesn't care about the size of the value.

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

Move some code from doInitialization to runOnFunction

This has no observable behavior change, it just makes the state
insertion pass look a little more like normal passes.

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

[X86] Remove some unused encoding checks from the disassembler table building.

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

[X86] Add some missing reversed forms of XOP instructions.

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

[PM/AA] Wire up TBAA to the new pass manager's registry and test it.

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

[PM/AA] Wire up the scoped-no-alias AA to the new pass manager's
registry and test it.

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

[PM/AA] Wire up SCEVAA to the new pass manager's registry and test it.

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

MachineCopyPropagation: Introduce Reg2MIMap typedef; NFC

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

MachineCopyPropagation: Move variables from function to pass

This avoids unnecessarily passing them around when calling helper
functions. It may also be slightly faster to call clear() on the
datastructures instead of freshly initializing them for each block.

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

MachineCopyPropagation: Use ranged for, cleanup; NFC

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

MachineCopyPropagation: Use assert() instead of if{report_error()} for 'impossible' condition

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

[PM/AA] Wire up CFLAA to the new pass manager fully, and port one of its
tests over to exercise this code.

This uncovered a few missing bits here and there in the analysis, but
nothing interesting.

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

[PM/AA] Port alias analysis evaluator to the new pass manager, and use
it to actually test the new pass manager AA wiring.

This patch was extracted from the (somewhat too large) D12357 and
rebosed on top of the slightly different design of the new pass manager
AA wiring that I just landed. With this we can start testing the AA in
a thorough way with the new pass manager.

Some minor cleanups to the code in the pass was necessitated here, but
otherwise it is a very minimal change.

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

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

fixing msvc warning.

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

[SCEV] Don't spell `SCEV *` variables as `Scev`; NFC

I missed a spot in rL261393.

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

[SCEV] Don't spell `SCEV *` variables as `Scev`; NFC

It reads odd since most other places name a `SCEV *` as `S`.  Pure
renaming change.

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

[SCEV] Don't use std::make_pair; NFC

`{A, B}` reads cleaner than `std::make_pair(A, B)`.

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

[SimplifyCFG] Merge together cleanuppads

Cleanuppads may be merged together if one is the only predecessor of the
other in which case a simple transform can be performed: replace the
a cleanupret with a branch and remove an unnecessary cleanuppad.

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

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

[X86ISelLowering] Fix TLSADDR lowering when shrink-wrapping is enabled.

TLSADDR nodes are lowered into actuall calls inside MC. In order to prevent
shrink-wrapping from pushing prologue/epilogue past them (which result
in TLS variables being accessed before the stack frame is set up), we
put markers, so that the stack gets adjusted properly.
Thanks to Quentin Colombet for guidance/help on how to fix this problem!

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

AMDGPU/SI: Use v_readfirstlane to legalize SMRD with VGPR base pointer

Summary:
Instead of trying to replace SMRD instructions with a VGPR base pointer
with an equivalent MUBUF instruction, we now copy the base pointer to
SGPRs using v_readfirstlane.

This is safe to do, because any load selected as an SMRD instruction
has been proven to have a uniform base pointer, so each thread in the
wave will have the same pointer value in VGPRs.

This will fix some errors on VI from trying to replace SMRD instructions
with addr64-enabled MUBUF instructions that don't exist.

Reviewers: arsenm, cfang, nhaehnle

Subscribers: arsenm, llvm-commits

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

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

[RegAllocFast] Properly track the physical register definitions on calls.

PR26485

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

[codeview] Fix emission of file changes in inline line tables

These are supposed to be file checksum table offsets, not file ids.

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

[sancov] sanitizer html report cosmetic improvements.

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

[X86ISelLowering] Provide a more informative assert message.

I stumbled upon this while debugging a lowering bug.

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

[X86ISelLowering] Merge two conditions inside a single if.

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

Revert r255691 "[LoopVectorizer] Refine loop vectorizer's register usage calculator by ignoring specific instructions."

It caused PR26509.

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

Revert r253557 "Alternative to long nops for X86 CPUs, by Andrey Turetsky"

Turns out the new nop sequences aren't actually nops on x86_64 (PR26554).

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

llvm-dwp: Improve performance (N^2 to amortized N) by using a MapVector instead of linear searches through a vector

Figured this would be a problem, but didn't want to jump the gun - large
inputs demonstrate it pretty easily (mostly for type units, but might as
well do the same for CUs too). A random sample 6m27s -> 27s change.

Also, by checking this up-front for CUs (rather than when building the
cu_index) we can probably provide better error messages (see FIXMEs),
hopefully providing the name of the CUs rather than just their
signature.

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

Fix incorrect selection of AVX512 sqrt when OptForSize is on

Summary:
When optimizing for size, sqrt calls can be incorrectly selected as
AVX512 VSQRT instructions.  This is because X86InstrAVX512.td has a
`Requires<[OptForSize]>` in its `avx512_sqrt_scalar` multiclass
definition.  Even if the target does not support AVX512, the class can
apparently still be chosen, leading to an incorrect selection of
`vsqrtss`.

In PR26625, this lead to an assertion: Reg >= X86::FP0 && Reg <=
X86::FP6 && "Expected FP register!", because the `vsqrtss` instruction
requires an XMM register, which is not available on i686 CPUs.

Reviewers: grosbach, resistor, joker.eph

Subscribers: spatel, emaste, llvm-commits

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

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

[StatepointLowering] Minor non-semantic cleanups

Use auto, bring file up to coding standards etc.

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

[WebAssembly] Add another optimization idea to README.txt.

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

[AArch64][ShrinkWrap] Fix bug in prolog clobbering live reg when shrink wrapping.

Summary: See bug https://llvm.org/bugs/show_bug.cgi?id=26642

Reviewers: qcolombet, t.p.northover

Subscribers: aemerson, rengolin, mcrosier, llvm-commits

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

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

[StatepointLowering] Update StatepointMaxSlotsRequired correctly

Now that we don't always add an element to AllocatedStackSlots if we
don't find a pre-existing unallocated stack slot, bumping
StatepointMaxSlotsRequired to `NumSlots + 1` is not correct.  Instead
bump the statistic near the push_back, to
Builder.FuncInfo.StatepointStackSlots.size().

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

[StatepointLowering] Fix a mistake in rL261336

The check on MFI->getObjectSize() has to be on the FrameIndex, not on
the index of the FrameIndex in AllocatedStackSlots.  Weirdly, the tests
I added in rL261336 didn't catch this.

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

[LV] Vectorize first-order recurrences

This patch enables the vectorization of first-order recurrences. A first-order
recurrence is a non-reduction recurrence relation in which the value of the
recurrence in the current loop iteration equals a value defined in the previous
iteration. The load PRE of the GVN pass often creates these recurrences by
hoisting loads from within loops.

In this patch, we add a new recurrence kind for first-order phi nodes and
attempt to vectorize them if possible. Vectorization is performed by shuffling
the values for the current and previous iterations. The vectorization cost
estimate is updated to account for the added shuffle instruction.

Contributed-by: Matthew Simpson and Chad Rosier <mcrosier@codeaurora.org>
Differential Revision: http://reviews.llvm.org/D16197

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

[StatepointLowering] Change AllocatedStackSlots to use SmallBitVector

NFCI.  They key motivation here is that I'd like to use
SmallBitVector::all() in a later change.  Also, using a bit vector here
seemed better in general.

The only interesting change here is that in the failure case of
allocateStackSlot, we no longer (the equivalent of) push_back(true) to
AllocatedStackSlots.  As far as I can tell, this is fine, since we'd
never re-use those slots in the same StatepointLoweringState instance.

Technically there was no need to change the operator[] type accesses to
set() and test(), but I thought it'd be nice to make it obvious that
we're using something other than a std::vector like thing.

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

[StatepointLowering] Fix bug in allocateStackSlot

allocateStackSlot did not consider the size of the value to be spilled
before deciding to re-use a spill slot.  This was originally okay (since
originally we'd only ever spill pointers), but it became not okay when
we changed our scheme to directly spill vectors of pointers.

While this change fixes the bug pointed out, it has two performance
caveats:

 - It matches spill slot and spillee size exactly, while in theory we
   can spill, e.g., an 8 byte pointer into a 16 byte slot.  This is
   slightly complicated to fix since in the stackmaps section, we report
   the size of the spill slot as the size of the "indirect value"; and
   if they're no longer equivalent, we'll have to keep track of the
   (indirect) value size separately from the stack slot size.

 - It will "spuriously run out" of reusable slots, since we now have an
   second check in the search loop in addition to the availablity
   check (e.g. you had two free scalar slots, and you first ask for a
   vector slot followed by a scalar slot).  I'll fix this in a later
   commit.

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

[StatepointLowering] Clean up allocateStackSlot

This removes the unusual loop structure in allocateStackSlot in favor of
something more straightforward.  I've also removed the cautionary
comment in the function, which I suspect is historical cruft now, and
confuses more than it enlightens.

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

[X86] Change fixup-bw-inst.ll to test output with this optimization on and off.
Differential Revision: http://reviews.llvm.org/D17415

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

[LV] Fix PR26600: avoid out of bounds loads for interleaved access vectorization

Summary:
If we don't have the first and last access of an interleaved load group,
the first and last wide load in the loop can do an out of bounds
access. Even though we discard results from speculative loads,
this can cause problems, since it can technically generate page faults
(or worse).

We now discard interleaved load groups that don't have the first and
load in the group.

Reviewers: hfinkel, rengolin

Subscribers: rengolin, llvm-commits, mzolotukhin, anemet

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

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

AMDGPU/SI: Fix s_waitcnt insertion for flat instructions

Summary:
This was broken in r260694 which swapped the address and data operands
for flat store instructions.  The code in SIInsertWaits assumes
that the data operand always comes before the address operand, so
we need to add a special case for flat.

Reviewers: arsenm

Subscribers: arsenm, llvm-commits

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

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

[X86][AVX] Added fast-isel intrinsics tests

As discussed on PR24580, this patch adds some (more to come) initial fast-isel codegen tests to match the IR generated in clang/test/CodeGen/avx-builtins.c

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

Add support for merging strings with alignment larger than one char.

This will be used in a lld patch.

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

[SystemZ] Fix ABI for i128 argument and return types

According to the SystemZ ABI, 128-bit integer types should be
passed and returned via implicit reference.  However, this is
not currently implemented at the LLVM IR level for the i128
type.  This does not matter when compiling C/C++ code, since
clang will implement the implicit reference itself.

However, it turns out that when calling libgcc helper routines
operating on 128-bit integers, LLVM will use i128 argument and
return value types; the resulting code is not compatible with
the ABI used in libgcc, leading to crashes (see PR26559).

This should be simple to fix, except that i128 currently is not
even a legal type for the SystemZ back end.  Therefore, common
code will already split arguments and return values into multiple
parts.  The bulk of this patch therefore consists of detecting
such parts, and correctly handling passing via implicit reference
of a value split into multiple parts.  If at some time in the
future, i128 becomes a legal type, this code can be removed again.

This fixes PR26559.

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

[LPM] Document the new helpers to make it easy to get consistent require
and preserve behavior from loop passes.

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

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

[LPM] Factor all of the loop analysis usage updates into a common helper
routine.

We were getting this wrong in small ways and generally being very
inconsistent about it across loop passes. Instead, let's have a common
place where we do this. One minor downside is that this will require
some analyses like SCEV in more places than they are strictly needed.
However, this seems benign as these analyses are complete no-ops, and
without this consistency we can in many cases end up with the legacy
pass manager scheduling deciding to split up a loop pass pipeline in
order to run the function analysis half-way through. It is very, very
annoying to fix these without just being very pedantic across the board.

The only loop passes I've not updated here are ones that use
AU.setPreservesAll() such as IVUsers (an analysis) and the pass printer.
They seemed less relevant.

With this patch, almost all of the problems in PR24804 around loop pass
pipelines are fixed. The one remaining issue is that we run simplify-cfg
and instcombine in the middle of the loop pass pipeline. We've recently
added some loop variants of these passes that would seem substantially
cleaner to use, but this at least gets us much closer to the previous
state. Notably, the seven loop pass managers is down to three.

I've not updated the loop passes using LoopAccessAnalysis because that
analysis hasn't been fully wired into LoopSimplify/LCSSA, and it isn't
clear that those transforms want to support those forms anyways. They
all run late anyways, so this is harmless. Similarly, LSR is left alone
because it already carefully manages its forms and doesn't need to get
fused into a single loop pass manager with a bunch of other loop passes.

LoopReroll didn't use loop simplified form previously, and I've updated
the test case to match the trivially different output.

Finally, I've also factored all the pass initialization for the passes
that use this technique as well, so that should be done regularly and
reliably.

Thanks to James for the help reviewing and thinking about this stuff,
and Ben for help thinking about it as well!

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

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

[X86] Remove unused entries from the disassembler type enum.

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

Shuffle header file as per the Coding Standards

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

[SjLjEHPrepare] Simplify/cleanup code

No functional change is intended.

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

LegalizeDAG: Fix ExpandFCOPYSIGN assuming the same type on both inputs

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

[LPM] Actually test what the O2 pass pipeline consists of in key places,
especially the *structure* of it with respect to various pass managers.

This uncovers an absolute horror show of problems. This test shows just
how bad PR24804 is: we have a totaly of *seven* loop pass managers in
the main optimization pipeline.

I've tried to comment the various bits to the best of my knowledge, but
more enhancements here would be great.

Also great would be folks adding various test for other pipelines, I'm
focused on trying to fix the O2 pipeline. I just wanted a test to show
what I'm changing.

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

Add profile summary support for sample profile.

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

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

[SjLjEHPrepare] Don't grab pointers to functions in doInitialization

Certain optimization passes (like globaldce) can prune function
declaration that SjLjEHPrepare assumed would exit when it'd
runOnFunction.

This fixes PR26669.

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

[AA] Preserve the AA results wrapper pass as well as BasicAA in a few
more places to prevent gratuitous re-"runs" of these passes.

The passes themselves don't do any work when run, but we keep spending
time scheduling and running these needlessly when we really don't need
to do so.

This is the first patch towards fixing the really horrible loop pass
pipeline fragmentation pointed out by Sanjoy in PR24804.

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

[llvm-nm] In C++, main implicitly returns 0. Pointed out by David Blaikie.

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

Bug fix: use dyn_cast_or_null instead of dyn_cast

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

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

llvm-dwp: Don't test compression when zlib isn't available

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

llvm-dwp: Support compressed input

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

Minor code cleanups. NFC.

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

[sancov] widening default blacklist.

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

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

[sancov] Adding covered/uncovered tables to coverage report.

Summary:
This change adds 3 tables to html report:
- list of covered files with number of functions covered.
- list of not covered files
- list of not covered functions.

I tried to put most coverage-calculating functionality into
SourceCoverageData.

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

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

When printing MIR, output to errs() rather than outs().

Summary:
Without this, this command

  $ llvm-run llc -stop-after machine-cp -o - <( echo '' )

outputs an error, because we close stdout twice -- once when closing the
file opened for "-o", and again when closing outs().

Also clarify in the outs() definition that you can't ever call it if you
want to open your own raw_fd_ostream on stdout.

Reviewers: jroelofs, tstellarAMD

Subscribers: jholewinski, qcolombet, dsanders, llvm-commits

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

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

[CaptureTracking] Add a test case for pointer cmpxchg

This test builds on 261250 (IR support for cmpxchg of pointers) and 261245 (capture tracking support for cmpxchg) to show that correctly analyze the capturing of pointers in a cmpxchg of pointer type.

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

[IR] Extend cmpxchg to allow pointer type operands

Today, we do not allow cmpxchg operations with pointer arguments. We require the frontend to insert ptrtoint casts and do the cmpxchg in integers. While correct, this is problematic from a couple of perspectives:
1) It makes the IR harder to analyse (for instance, it make capture tracking overly conservative)
2) It pushes work onto the frontend authors for no real gain

This patch implements the simplest form of IR support. As we did with floating point loads and stores, we teach AtomicExpand to convert back to the old representation. This prevents us needing to change all backends in a single lock step change. Over time, we can migrate each backend to natively selecting the pointer type. In the meantime, we get the advantages of a cleaner IR representation without waiting for the backend changes.

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

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

[x86] fix initialization of PredictableSelectIsExpensive

This is effectively NFC because Atom is the only in-order x86 subtarget currently,
but the predicate would have become wrong if any other in-order CPU came along.

See related discussion in:
http://reviews.llvm.org/D16836

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

[CMake] Properly set CMAKE_BUILD_TYPE to Debug by default

Summary:
PR26666: CMAKE_BUILD_TYPE was previously being reset to blank.

Reviewers: rnk, beanz

Subscribers: llvm-commits

Patch By: Derek Bruening

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

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

Remove uses of builtin comma operator.

Cleanup for upcoming Clang warning -Wcomma.  No functionality change intended.

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

[ADT] Be less clever when using a nonce type for disambiguation.

Old compilers don't like constexpr, but we're only going to use this in one
place anyway: this file. Everyone else should go through PointerLikeTypeTraits.

Update to r261259.

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

[libFuzzer] only read MaxLen bytes from every file in the corpus to speedup loading the corpus

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

[PPCLoopDataPrefetch] Move pass to Transforms/Scalar/LoopDataPrefetch. NFC

This patch is part of the work to make PPCLoopDataPrefetch
target-independent
(http://thread.gmane.org/gmane.comp.compilers.llvm.devel/92758).

Obviously the pass still only used from PPC at this point.  Subsequent
patches will start driving this from ARM64 as well.

Due to the previous patch most lines should show up as moved lines.

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

[PPCLoopDataPrefetch] Remove PPC from some of the names. NFC

This is done only to make the next patch that move the pass out PPC to
Transforms easier to read.  After this most line should show up as moved
lines in that patch.

This patch is part of the work to make PPCLoopDataPrefetch
target-independent
(http://thread.gmane.org/gmane.comp.compilers.llvm.devel/92758).

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

[WinEH] Hoist state stores from successors

If we know that all of our successors want to be in the exact same
state, it makes sense to hoist the state transition into their common
predecessor.

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

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

[ADT] Fix PointerEmbeddedInt when the underlying type is uintptr_t.

...and when you try to store negative values in it.

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

[IR] Straighten out bundle overload of IRBuilder::CreateCall

IRBuilder has two ways of putting bundle operands on calls: the default
operand bundle, and an overload of CreateCall that takes an operand
bundle list.

Previously, this overload used a default argument of None. This made it
impossible to distinguish between the case were the caller doesn't care
about bundles, and the case where the caller explicitly wants no
bundles. We behaved as if they wanted the latter behavior rather than
the former, which led to problems with simplifylibcalls and WinEH.

This change fixes it by making the parameter non-optional, so we can
distinguish these two cases.

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

[X86ISelLowering] Use isPowerof2 instead of rewriting it. NFC.

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

Add support for invoke/landingpad/resume in C API test

Summary: As per title. There was a lot of part missing in the C API, so I had to extend the invoke and landingpad API.

Reviewers: echristo, joker.eph, Wallbraker

Subscribers: llvm-commits

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

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

Restrict scope of variables [NFC]

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

[CaptureTracking] Support atomicrmw and cmpxchg

These atomic operations are conceptually both a load and store from the same location. As such, we can treat them as the most conservative of those two components which in practice, means we can treat them like stores. An cmpxchg or atomicrmw captures the values, but not the locations accessed.

Note: We can probably be more aggressive about the comparison value in an cmpxhg since to have it be in memory, it must already be captured, but I figured it was better to avoid that for the moment.

Note 2: It turns out that since we don't actually support cmpxchg of pointer type, writing a negative test is impossible.

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

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

[DebugInfoPDB] Add source / line number accessors for PDB.

This patch adds a variety of different methods to query source
and line number information from PDB files.

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

Add more triples after r261235

Since the behaviour is now different between Darwin and non-Darwin,
more triples are needed :-/

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

[AArch64] Reduce vector insert/extract cost for Kryo

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

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

Revert to extend i8/i16 return values on Darwin (PR26665)

In r260133, LLVM was changed to no longer extend i8/i16 return values,
as it's not required by the ABI. However, code was found in the wild
that relies on the old behaviour on Darwin, so this commit reverts
back to that old behaviour for Darwin.

On other platforms, it's less likely that code would be depending on
the old behaviour, as GCC and MSVC haven't been extending such return
values.

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

Make header self-contained. NFC.

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

[Hexagon] Remove redundant check.

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

Stop creating covmap as note section on ELF

covmap needs to created as non allocatable, but not with
SHT_NOTE. The latter was needed to workaround a problem
of BFD linker with gc, which is no longer needed. (A more
proper longer term fix requires changing FE driver to force
referencing the section using linker script).

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

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

AMDGPU/SI: add llvm.amdgcn.image.load/store[.mip] intrinsics

Summary:
These correspond to IMAGE_LOAD/STORE[_MIP] and are going to be used by Mesa
for the GL_ARB_shader_image_load_store extension.

IMAGE_LOAD is already matched by llvm.SI.image.load. That intrinsic has
a legacy name and pretends not to read memory.

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

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

[Hexagon] Fix compilation error with GCC 6

Compiling Hexagon target with GCC 6 produces "error: should have been
declared inside" due to GCC PR c++/69657 which was merged.

Properly wrapping operator<<() definitions within the namespace llvm
fixes the issue.

Author: domagoj.stolfa

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

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

[Hexagon] Implement TLS support

Patch by Anand Kodnani.

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

Reapply commit r259357 with a fix for PR26629

Commit r259357 was reverted because it caused PR26629. We were assuming all
roots of a vectorizable tree could be truncated to the same width, which is not
the case in general. This commit reapplies the patch along with a fix and a new
test case to ensure we don't regress because of this issue again. This should
fix PR26629.

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