llvm/test/CodeGen/X86/llc-override-mcpu-mattr.ll: Tweak not to be affected by x64 Calling Convention.

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

Update InstCombine to transform aggregate loads into scalar loads.

Summary:
One step further getting aggregate loads and store being optimized
properly. This will only handle struct with one element at this point.

Test Plan: Added unit tests for the new supported cases.

Reviewers: chandlerc, joker-eph, joker.eph, majnemer

Reviewed By: majnemer

Subscribers: pete, llvm-commits

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

Patch by Amaury Sechet.

From: Amaury Sechet <amaury@fb.com>

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

[SanitizerCoverage] Introduce SanitizerCoverageOptions struct.

Summary:
This gives frontend more precise control over collected coverage
information. User can still override these options by passing
-mllvm flags.

No functionality change.

Test Plan: regression test suite.

Reviewers: kcc

Subscribers: llvm-commits

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

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

IR: Initialize DerefOrNullBytes in the AttrBuilder constructors

MSAN pointed out that this value is used uninitialized:

    http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/3678

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

InstrProf: Simplify looking up sections for coverage data

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

[JumpThreading] Simplify comparisons when simplifying branches

If we have recognized that a conditional is constant at a particular location in the code (while trying to decide if we can simplify a conditional branch), we can eagerly replace that condition with a constant if it's definition is post dominated by the branch in question.

In practice, this ends up being a compile time savings at most. JumpThreading would have visited each using branch anyways. CVP would have visited the cmp itself again. Unless LVI gives up early, we shouldn't gain any addition power by doing this transformation early. What we do gain is simplicity and compile time.

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

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

[lib/Fuzzer] add dfsan_weak_hook_memcmp, enable the test that uses it, simplify the test runner

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

Added support for building against Android API-9 SDK

Created an abstraction for log2, llvm::Log2 in Support/MathExtras.h

Hid Android problems inside of it

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

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

Revert "[opaque pointer type] Pass explicit pointer type through GEP constant folding"

Causes regressions in Clang. Reverting while I investigate.

This reverts commit r236670.

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

Let llc and opt override "-target-cpu" and "-target-features" via command line
options.

This commit fixes a bug in llc and opt where "-mcpu" and "-mattr" wouldn't
override function attributes "-target-cpu" and "-target-features" in the IR.

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

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

[X86MCInst] Move LowerSTATEPOINT to inside X86AsmPrinter.  NFC.

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

[X86MCInst] Clean up LowerSTATEPOINT: variable names.  NFC.

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

[Statepoints] Clean up PlaceSafepoints.cpp: de-duplicate code.

Common duplicated code and remove unnecessary code.

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

[Statepoints] Clean up PlaceSafepoints.cpp: variable naming.

Use CamelCase.  NFC.

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

[IRBuilder] Add a CreateGCStatepointInvoke.

Renames the original CreateGCStatepoint to CreateGCStatepointCall, and
moves invoke creating functionality from PlaceSafepoints.cpp to
IRBuilder.cpp.

This changes the labels generated for PlaceSafepoints/invokes.ll so use
a regex there to make the basic block labels more resilient.

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

Factor out a function which determines the cpu and feature strings based on
command line options -mcpu and -mattr. NFC.

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

[opaque pointer type] Pass explicit pointer type through GEP constant folding

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

YAML: Fix crash in the skip method of KeyValueNode class.

This commit changes the 'skip' method in the 'KeyValueNode' class
to ensure that it doesn't dereference a null pointer when calling
the 'skip' method of its value child node. It also adds a unittest
that ensures that the crash doesn't occur.

This change is motivated by a patch that implements parsing
of YAML block scalars (http://reviews.llvm.org/D9503), as one
of the unittests in that patch triggered this problem.

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

Change typeIncompatible to return an AttrBuilder instead of new-ing an AttributeSet.

This makes use of the new API which can remove attributes from a set given a builder.

This is much faster than creating a temporary set and reduces llc time by about 0.3% which was all spent creating temporary attributes sets on the context.

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

Update all comments to match the previous commit.  NFC

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

Add remove method to operate on AttrBuilder instead of AttributeSet.

Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that.

Now we can just remove any attributes from the (lightweight and really temporary) builder itself.

Will be used in a future commit to remove some temporary attributes sets.

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

InstrProf: Give coverage its own errors instead of piggy backing on instrprof

Since the coverage mapping reader and the instrprof reader were
emitting a shared set of error codes, the error messages you'd get
back from llvm-cov were ambiguous about what was actually wrong. Add
another error category to fix this.

I've also improved the wording on a couple of the instrprof errors,
for consistency.

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

InstrProf: Remove a function that just returns its argument (NFC)

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

YAML: Extract the code that skips a comment into a separate method, NFC.

This commit extracts the code that skips over a YAML comment from
the 'scanToNextToken' method into a separate 'skipComment' method.

This refactoring is motivated by a patch that implements parsing
of YAML block scalars (http://reviews.llvm.org/D9503), as the
method that parses a block scalar reuses the 'skipComment' method.

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

Remove unnecessary #ifndef NDEBUG guard around assert.  NFC.

Found by Hal Finkel in the review of AttributeSets.  http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150504/275058.html

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

Bitcode: Set LastDL after writing DebugLocs

Somehow I dropped this in r233585, and we haven't had `DEBUG_LOC_AGAIN`
records since.  Add it back.  Also tests that the output assembly looks
okay.

Fixes PR23436.

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

Handle dead defs in the if converter.

We had code such as this:
  r2 = ...
  t2Bcc

label1:
  ldr ... r2

label2;
  return r2<dead, def>

The if converter was transforming this to
   r2<def> = ...
   return [pred] r2<dead,def>
   ldr <r2, kill>
   return

which fails the machine verifier because the ldr now reads from a dead def.

The fix here detects dead defs in stepForward and passes them back to the caller in the clobbers list.  The caller then clears the dead flag from the def is the value is live.

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

[lib/Fuzzer] remove dfsan_fuzzer_abi.list -- its contents are now moved to dfsan proper

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

[RegisterCoalescer] Make sure each live-range has only one component, as
demanded by the machine verifier.
After shrinking a live-range to its uses, it is possible to create several
smaller live-ranges. When this happens, shrinkToUses returns true and we need to
split the different components into their own live-ranges.

The problem does not reproduce on any in-tree target but Jonas Paulsson
<jonas.paulsson@ericsson.com>, who reported the problem, checked that this patch
fixes the issue.

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

[lib/Fuzzer] add a fuzzer test for memcmp (does not work yet)

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

Fix link failure on MinGW due to use of CoInitialize.

ole32 is considered a default library with MSVC, but apparently
not with MinGW.  Since we use CoInitialize, we need to explicitly
link against it in LLVMSupport for a MinGW build.

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

A few fixes for llvm-symbolizer on Windows.

Specifically, this patch correctly respects the -demangle option,
and additionally adds a hidden --relative-address option allows
input addresses to be relative to the module load address instead
of absolute addresses into the image.

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

[lib/Fuzzer] rename TestOneInput to LLVMFuzzerTestOneInput to make it more unique

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

Fix incorrect kill flags in fastisel.

If called twice in the same BB on the same constant, FastISel::fastEmit_ri_ was marking the materialized vreg as killed on each use, instead of only the last use.

Change this to only mark the last use as killed by making earlier uses check if the vreg is already used elsewhere.

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

[x86] Fix register class of folded load index reg.

When folding a load in to another instruction, we need to fix the class of the index register
Otherwise, it could be something like GR64 not GR64_NOSP and would fail the machine verifier.

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

[SanitizerCoverage] Fix a couple of typos. NFC.

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

MC: Skip names of temporary symbols in object streamer

Don't create names for temporary symbols when using an object streamer.
The names never make it to the output anyway.  From the starting point
of r236629, my heap profile says this drops peak memory usage from 1100
MB to 1058 MB for CodeGen of `verify-uselistorder`, a savings of almost
4% on peak memory, and removes `StringMap<bool, BumpPtrAllocator...>`
from the profile entirely.

(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)

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

CodeGen: move over-zealous assert into actual if statement.

It's quite possible to encounter an insertvalue instruction that's more deeply
nested than the value we're looking for, but when that happens we really
mustn't compare beyond the end of the index array.

Since I couldn't see any guarantees about what comparisons std::equal makes, we
probably need to directly check the size beforehand. In practice, I suspect
most std::equal implementations would probably bail early, which would be OK.
But just in case...

rdar://20834485

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

DwarfDebug: Emit number of bytes in .debug_loc entry directly

Emit the number of bytes in a `.debug_loc` entry directly.  The old code
created temp labels (expensive), emitted the difference between them,
and then emitted one on each side of the relevant bytes.

(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`
(the optimized version of ld64's `-save-temps` when linking the
`verify-uselistorder` executable in an LTO bootstrap).  I've hacked
`MCContext::Allocate()` to just call `malloc()` instead of using the
`BumpPtrAllocator` so that the heap profile is easier to read.  As far
as peak memory is concerned, `MCContext::Allocate()` is equivalent to a
leak, since it only gets freed at process teardown.

In my heap profile, this patch drops memory usage of
`DwarfDebug::emitDebugLoc()` from 132.56 MB (11.4%) down to 29.86 MB
(2.7%) at peak memory.  Some of that must be noise from `SmallVector`
(or other) allocations -- peak memory only dropped from 1160 MB down to
1100 MB -- but this nevertheless shaves 5% off the top.)

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

Implement `createSanitizerCtor`, common helper function for all sanitizers

Summary:
This helper function creates a ctor function, which calls sanitizer's
init function with given arguments. This constructor is then expected
to be added to module's ctors. The patch helps unifying how sanitizer
constructor functions are created, and how init functions are called
across all sanitizers.

Reviewers: kcc, samsonov

Subscribers: llvm-commits

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

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

[WinEH] Improve fatal error message about failed demotion

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

[SelectionDAG] Delete SelectionDAGBuilder::removeValue. NFC.

SelectionDAGBuilder::removeValue is dead now, after rL236563.

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

Allow 0-weight branches in BranchProbabilityInfo.

Summary:
When computing branch weights in BPI, we used to disallow branches with
weight 0. This is a minor nuisance, because a branch with weight 0 is
different to "don't have information". In the context of
instrumentation, it may mean "never executed", in the context of
sampling, it means "never or seldom executed".

In allowing 0 weight branches, I ran into issues with the switch
expansion code in selection DAG. It is currently hardwired to not handle
branches with weight 0. To maintain the current behaviour, I changed it
to use 1 when it finds 0, but perhaps the algorithm needs changes to
tolerate branches with weight zero.

Reviewers: hansw

Subscribers: llvm-commits

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

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

Add missing dereferenceable_or_null getters

Summary: Add missing dereferenceable_or_null getters required for
http://reviews.llvm.org/D9253 change. Separated from the D9253 review.

Patch by Artur Pilipenko!

Reviewers: sanjoy

Reviewed By: sanjoy

Subscribers: llvm-commits

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

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

[X86] Disable loop unrolling in loop vectorization pass when VF is 1.

The patch disabled unrolling in loop vectorization pass when VF==1 on x86 architecture,
by setting MaxInterleaveFactor to 1. Unrolling in loop vectorization pass may introduce
the cost of overflow check, memory boundary check and extra prologue/epilogue code when
regular unroller will unroll the loop another time. Disable it when VF==1 remove the
unnecessary cost on x86. The same can be done for other platforms after verifying
interleaving/memory bound checking to be not perf critical on those platforms.

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

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

Add ChangeTo* to MachineOperand for symbols

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

Add bitcode test to verify functions can be materialized out of order.

Summary:
Adds test to check that when getLazyBitcodeModule is called:
1) Functions are not materailzed by default.
2) Only the requested function gets materialized (if no block addresses
   are used).

Reviewers: jvoung, rafael

Reviewed By: rafael

Subscribers: llvm-commits

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

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

Readd the regression test from r236584. Calling convention fixed to linux.

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

[ARM] Fast-Isel was incorrectly selecting <2 x double> adds.

With neon enabled, we reach SelectBinaryFPOp and are able to get registers for a <2 x double> add.

However, we shouldn't actually attempt arithmetic on it as ARMIselLowering says "v2f64 is legal so that QR subregs can be extracted as f64 elements, but neither Neon nor VFP support any arithmetic operations on it."

This commit disables SelectBinaryFPOp for any vector types.  There's already a FIXME to try handle neon.  Doing so would require fixing this conditional which isn't safe for vectors 'VT == MVT::f64 || VT == MVT::i64'

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

[PPC64LE] Adjust vector splats during VSX swap optimization

The initial code drop for VSX swap optimization permitted the
optimization only when all operations in a web of related computation
are lane-insensitive.  For some lane-sensitive operations, we can
still permit the optimization provided that we make adjustments to
those operations.  This patch adds special handling for vector splats
so that their presence doesn't kill the optimization.

Vector splats are lane-sensitive since they identify by number a
vector element to be used as the source of a splat.  When swap
optimizations take place, the desired vector element will move to the
opposite doubleword of the quadword vector.  We thus replace the index
I by (I + N/2) % N, where N is the number of elements in the vector.

A new test case is added to test that swap optimization succeeds when
vector splats are present, and that the proper input element is used
as the source of the splat.

An ancillary change removes SH_BUILDVEC as one of the kinds of special
handling that may be required by VSX swap optimization.  From
experience with GCC, I had expected to need some modifications for
vector build operations, but I did not find that to be the case.

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

Reformat.

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

Revert r236546, "propagate IR-level fast-math-flags to DAG nodes (NFC)"

It caused undefined behavior.

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

[ARM] generate VMAXNM/VMINNM for a compare followed by a select, in safe math mode too

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

Revert regression test from r236584.

Temporary remove a regression test added in r236584. It fails on Windows.

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

SelectionDAG: Handle out-of-bounds index in extract vector element

Summary: This patch correctly handles undef case of EXTRACT_VECTOR_ELT node where the element index is constant and not less than vector size.

Test Plan:
CodeGen for X86 test included.
Also one incorrect regression test fixed.

Reviewers: qcolombet, chandlerc, hfinkel

Reviewed By: hfinkel

Subscribers: hfinkel, llvm-commits

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

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

[DomTree] verifyDomTree to unconditionally perform DT verification

I folded the check for the flag -verify-dom-info into the only caller
where I think it is supposed to be checked: verifyAnalysis.  (The idea
of the flag is to enable this expensive verification in
verifyPreservedAnalysis.)

I'm assuming that when manually scheduling the verification pass
with -passes=verify<domtree>, we do want to perform the verification.

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

[ARM][FastISel] Use TST #1 instead of CMP #0 for select.

Since r234249, i1 are sext instead of zext; because of that, doing
"CMP rN, #0; IT EQ/NE" isn't correct anymore.

"TST #1" is the conservatively correct alternative - the tradeoff being
that it doesn't have a 16-bit encoding -, so use that instead.

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

[Statepoints] Remove broken test case.

statepoint-indirect-return.ll breaks on linux systems.  Delete the test
case to make the bots green while I figure out what the right fix is.

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

[IRBuilder] Fix indentation.  NFC.

Whitespace-only change.

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

[Statepoint] Clean up StatepointLowering: symbolic constants.

For accessors in the `Statepoint` class, use symbolic constants for
offsets into the argument vector instead of literals.  This makes the
code intent clearer and simpler to change.

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

[Statepoint] Clean up Statepoint.h: clang-format.

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

[Statepoint] Clean up Statepoint.h: accessor names.

Use getFoo() as accessors consistently and some other naming changes.

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

[StatepointLowering] Don't create temporary instructions.  NFCI.

Summary:
Instead of creating a temporary call instruction and lowering that, use
SelectionDAGBuilder::lowerCallOperands.

Reviewers: reames

Subscribers: llvm-commits

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

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

[WinEH] Reset WinEHPrepare::SEHExceptionCodeSlot when we're done.

This caused a use-after-free on test/CodeGen/X86/win32-eh.ll
No functional change intended.

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

InstrProf: Strip filename prefixes from the names we display for coverage

For consumers of coverage data, any filename prefixes we store in the
profile data are just noise. Strip this prefix if it exists.

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

[X86 fast-isel] Constrain the index reg class to not include SP.

The index reg on instructions with complex address modes is a GPR64_NOSP.  Constrain it to appease the machine verifier.

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

[SelectionDAG] Make an argument optional in RFV::getCopyToRegs.  NFC.

Summary:
We default the value argument to nullptr.  The only use of the value is
in diagnosePossiblyInvalidConstraint and that seems to be resilient to
it being nullptr.

Reviewers: atrick, reames

Subscribers: llvm-commits

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

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

[SelectionDAG] Move RegsForValue into SelectionDAGBuilder.h. NFC.

Summary:
The exported class will be used in later change, in
StatepointLowering.cpp.  It is still internal to SelectionDAG (not
exported via include/).

Reviewers: reames, atrick

Subscribers: llvm-commits

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

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

[SelectionDAG] Pass explicit type to lowerCallOperands. NFC.

Summary:
Currently this does not change anything, but change will be used in a
later change to StatepointLowering.cpp

Reviewers: reames, atrick

Subscribers: llvm-commits

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

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

[StatepointLowering] Rename variable, NFC.

Rename LoweredArgs to LoweredMetaArgs to clarify intent.

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

Fix IfConverter to handle regmask machine operands.

Note, this is a recommit of r236515 after fixing an error in r236514.  The buildbot ran fast enough that it picked up r236514 prior to r236515 and threw an error.  r236515 itself ran 'make check' without errors.

Original commit message follows:

A regmask (typically seen on a call) clobbers the set of registers it lists.  The IfConverter, in UpdatePredRedefs, was handling register defs, but not regmasks.

These are slightly different to a def in that we need to add both an implicit use and def to appease the machine verifier.  Otherwise, uses after the if converted call could think they are reading an undefined register.

Reviewed by Matthias Braun and Quentin Colombet.

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

[lib/Fuzzer] on crash print the contents of the crashy input as base64

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

propagate IR-level fast-math-flags to DAG nodes (NFC)

This patch adds the minimum plumbing necessary to use IR-level
fast-math-flags (FMF) in the backend without actually using
them for anything yet. This is a follow-on to:
http://reviews.llvm.org/rL235997

...which split the existing nsw / nuw / exact flags and FMF
into their own struct.

There are 2 structural changes here:

1. The main diff is that we're preparing to extend the optimization
flags to affect more than just binary SDNodes. Eg, IR intrinsics
( https://llvm.org/bugs/show_bug.cgi?id=21290 ) or non-binop nodes
that don't even exist in IR such as FMA, FNEG, etc.

2. The other change is that we're actually copying the FP fast-math-flags
from the IR instructions to SDNodes.

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

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

use range-based for-loop; NFC

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

Added Andrey Churbanov as the owner of the OpenMP runtime library code

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

[Inliner] Discard empty COMDAT groups

COMDAT groups which have become rendered unused because of inline are
discardable if we can prove that we've made the group empty.

This fixes PR22285.

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

Refactor UpdatePredRedefs and StepForward to avoid duplication.  NFC

Note, this is a reapplication of r236515 with a fix to not assert on non-register operands, but instead only handle them until the subsequent commit.  Original commit message follows.

The code was basically the same here already.  Just added an out parameter for a vector of seen defs so that UpdatePredRedefs can call StepForward first, then do its own post processing on the seen defs.

Will be used in the next commit to also handle regmasks.

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

Thumb2SizeReduction: Check the correct set of registers for LDMIA.

The register set for LDMIA begins at offset 3, not 4. We were previously
missing the short encoding of this instruction in the case where the base
register was the first register in the register set.

Also clean up some dead code:

- The isARMLowRegister check is redundant with what VerifyLowRegs does;
  replace with an assert.
- Remove handling of LDMDB instruction, which has no short encoding (and
  does not appear in ReduceTable).

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

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

[DAGCombiner] Account for getVectorIdxTy() when narrowing vector load

This patch makes ReplaceExtractVectorEltOfLoadWithNarrowedLoad convert
the element number from getVectorIdxTy() to PtrTy before doing pointer
arithmetic on it.  This is needed on z, where element numbers are i32
but pointers are i64.

Original patch by Richard Sandiford.

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

[DAGCombiner] Fix ReplaceExtractVectorEltOfLoadWithNarrowedLoad for BE

For little-endian, the function would convert (extract_vector_elt (load X), Y)
to X + Y*sizeof(elt).  For big-endian it would instead use
X + sizeof(vec) - Y*sizeof(elt).  The big-endian case wasn't right since
vector index order always follows memory/array order, even for big-endian.
(Note that the current handling has to be wrong for Y==0 since it would
access beyond the end of the vector.)

Original patch by Richard Sandiford.

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

[LegalizeVectorTypes] Allow single loads and stores for more short vectors

When lowering a load or store for TypeWidenVector, the type legalizer
would use a single load or store if the associated integer type was legal.
E.g. it would load a v4i8 as an i32 if i32 was legal.

This patch extends that behavior to promoted integers as well as legal ones.
If the integer type for the full vector width is TypePromoteInteger,
the element type is going to be TypePromoteInteger too, and it's still
better to use a single promoting load or truncating store rather than N
individual promoting loads or truncating stores.  E.g. if you have a v2i8
on a target where i16 is promoted to i32, it's better to load the v2i8 as
an i16 rather than load both i8s individually.

Original patch by Richard Sandiford.

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

[SystemZ] Add vector intrinsics

This adds intrinsics to allow access to all of the z13 vector instructions.
Note that instructions whose semantics can be described by standard LLVM IR
do not get any intrinsics.

For each instructions whose semantics *cannot* (fully) be described, we
define an LLVM IR target-specific intrinsic that directly maps to this
instruction.

For instructions that also set the condition code, the LLVM IR intrinsic
returns the post-instruction CC value as a second result.  Instruction
selection will attempt to detect code that compares that CC value against
constants and use the condition code directly instead.

Based on a patch by Richard Sandiford.

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

[SystemZ] Mark v1i128 and v1f128 as unsupported

The ABI specifies that <1 x i128> and <1 x fp128> are supposed to be
passed in vector registers.  We do not yet support those types, and
some infrastructure is missing before we can do so.

In order to prevent accidentally generating code violating the ABI,
this patch adds checks to detect those types and error out if user
code attempts to use them.

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

[SystemZ] Handle sub-128 vectors

The ABI allows sub-128 vectors to be passed and returned in registers,
with the vector occupying the upper part of a register.  We therefore
want to legalize those types by widening the vector rather than promoting
the elements.

The patch includes some simple tests for sub-128 vectors and also tests
that we can recognize various pack sequences, some of which use sub-128
vectors as temporary results.  One of these forms is based on the pack
sequences generated by llvmpipe when no intrinsics are used.

Signed unpacks are recognized as BUILD_VECTORs whose elements are
individually sign-extended.  Unsigned unpacks can have the equivalent
form with zero extension, but they also occur as shuffles in which some
elements are zero.

Based on a patch by Richard Sandiford.

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

[SystemZ] Add CodeGen support for scalar f64 ops in vector registers

The z13 vector facility includes some instructions that operate only on the
high f64 in a v2f64, effectively extending the FP register set from 16
to 32 registers.  It's still better to use the old instructions if the
operands happen to fit though, since the older instructions have a shorter
encoding.

Based on a patch by Richard Sandiford.

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

[SystemZ] Add CodeGen support for v4f32

The architecture doesn't really have any native v4f32 operations except
v4f32->v2f64 and v2f64->v4f32 conversions, with only half of the v4f32
elements being used.  Even so, using vector registers for <4 x float>
and scalarising individual operations is much better than generating
completely scalar code, since there's much less register pressure.
It's also more efficient to do v4f32 comparisons by extending to 2
v2f64s, comparing those, then packing the result.

This particularly helps with llvmpipe.

Based on a patch by Richard Sandiford.

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

[SystemZ] Add CodeGen support for v2f64

This adds ABI and CodeGen support for the v2f64 type, which is natively
supported by z13 instructions.

Based on a patch by Richard Sandiford.

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

[SystemZ] Add CodeGen support for integer vector types

This the first of a series of patches to add CodeGen support exploiting
the instructions of the z13 vector facility.  This patch adds support
for the native integer vector types (v16i8, v8i16, v4i32, v2i64).

When the vector facility is present, we default to the new vector ABI.
This is characterized by two major differences:
- Vector types are passed/returned in vector registers
  (except for unnamed arguments of a variable-argument list function).
- Vector types are at most 8-byte aligned.

The reason for the choice of 8-byte vector alignment is that the hardware
is able to efficiently load vectors at 8-byte alignment, and the ABI only
guarantees 8-byte alignment of the stack pointer, so requiring any higher
alignment for vectors would require dynamic stack re-alignment code.

However, for compatibility with old code that may use vector types, when
*not* using the vector facility, the old alignment rules (vector types
are naturally aligned) remain in use.

These alignment rules are not only implemented at the C language level
(implemented in clang), but also at the LLVM IR level.  This is done
by selecting a different DataLayout string depending on whether the
vector ABI is in effect or not.

Based on a patch by Richard Sandiford.

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

[SystemZ] Add z13 vector facility and MC support

This patch adds support for the z13 processor type and its vector facility,
and adds MC support for all new instructions provided by that facilily.

Apart from defining the new instructions, the main changes are:

- Adding VR128, VR64 and VR32 register classes.
- Making FP64 a subclass of VR64 and FP32 a subclass of VR32.
- Adding a D(V,B) addressing mode for scatter/gather operations
- Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields.
  Until now all immediate operands have been the same width as the
  underlying field (hence the assert->return change in decode[SU]ImmOperand).

In addition, sys::getHostCPUName is extended to detect running natively
on a z13 machine.

Based on a patch by Richard Sandiford.

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

Revert "Refactor UpdatePredRedefs and StepForward to avoid duplication.  NFC"

This reverts commit 963cdbccf6e5578822836fd9b2ebece0ba9a60b7 (ie r236514)

This is to get the bots green while i investigate.

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

Revert "Fix IfConverter to handle regmask machine operands."

This reverts commit b27413cbfd78d959c18e713bfa271fb69e6b3303 (ie r236515).

This is to get the bots green while i investigate the failures.

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

Fix IfConverter to handle regmask machine operands.

A regmask (typically seen on a call) clobbers the set of registers it lists.  The IfConverter, in UpdatePredRedefs, was handling register defs, but not regmasks.

These are slightly different to a def in that we need to add both an implicit use and def to appease the machine verifier.  Otherwise, uses after the if converted call could think they are reading an undefined register.

Reviewed by Matthias Braun and Quentin Colombet.

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

Refactor UpdatePredRedefs and StepForward to avoid duplication.  NFC

The code was basically the same here already.  Just added an out parameter for a vector of seen defs so that UpdatePredRedefs can call StepForward first, then do its own post processing on the seen defs.

Will be used in the next commit to also handle regmasks.

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

Fix typo in assert message. NFC.

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

Fix the clang -Werror build, use of uninitialized variable.

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

Update BasicAliasAnalysis to understand that nothing aliases with undef values.
It got this in some cases (if one of them was an identified object), but not in all cases.

This caused stores to undef to block load-forwarding in some cases, etc.

Added test to Transforms/GVN to verify optimization occurs as expected.

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

[opaque pointer type] Track explicit GEP pointee type through in-memory IR

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

Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86"

This reverts commit r236360.

This change exposed a bug in WinEHPrepare by opting win32 code into EH
preparation. We already knew that WinEHPrepare has bugs, and is the
status quo for x64, so I don't think that's a reason to hold off on this
change. I disabled exceptions in the sanitizer tests in r236505 and an
earlier revision.

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

[ShrinkWrap] Add (a simplified version) of shrink-wrapping.

This patch introduces a new pass that computes the safe point to insert the
prologue and epilogue of the function.
The interest is to find safe points that are cheaper than the entry and exits
blocks.

As an example and to avoid regressions to be introduce, this patch also
implements the required bits to enable the shrink-wrapping pass for AArch64.

** Context **

Currently we insert the prologue and epilogue of the method/function in the
entry and exits blocks. Although this is correct, we can do a better job when
those are not immediately required and insert them at less frequently executed
places.
The job of the shrink-wrapping pass is to identify such places.

** Motivating example **

Let us consider the following function that perform a call only in one branch of
a if:
define i32 @f(i32 %a, i32 %b)  {
 %tmp = alloca i32, align 4
 %tmp2 = icmp slt i32 %a, %b
 br i1 %tmp2, label %true, label %false

true:
 store i32 %a, i32* %tmp, align 4
 %tmp4 = call i32 @doSomething(i32 0, i32* %tmp)
 br label %false

false:
 %tmp.0 = phi i32 [ %tmp4, %true ], [ %a, %0 ]
 ret i32 %tmp.0
}

On AArch64 this code generates (removing the cfi directives to ease
readabilities):
_f:                                     ; @f
; BB#0:
  stp x29, x30, [sp, #-16]!
  mov  x29, sp
  sub sp, sp, #16             ; =16
  cmp  w0, w1
  b.ge  LBB0_2
; BB#1:                                 ; %true
  stur  w0, [x29, #-4]
  sub x1, x29, #4             ; =4
  mov  w0, wzr
  bl  _doSomething
LBB0_2:                                 ; %false
  mov  sp, x29
  ldp x29, x30, [sp], #16
  ret

With shrink-wrapping we could generate:
_f:                                     ; @f
; BB#0:
  cmp  w0, w1
  b.ge  LBB0_2
; BB#1:                                 ; %true
  stp x29, x30, [sp, #-16]!
  mov  x29, sp
  sub sp, sp, #16             ; =16
  stur  w0, [x29, #-4]
  sub x1, x29, #4             ; =4
  mov  w0, wzr
  bl  _doSomething
  add sp, x29, #16            ; =16
  ldp x29, x30, [sp], #16
LBB0_2:                                 ; %false
  ret

Therefore, we would pay the overhead of setting up/destroying the frame only if
we actually do the call.

** Proposed Solution **

This patch introduces a new machine pass that perform the shrink-wrapping
analysis (See the comments at the beginning of ShrinkWrap.cpp for more details).
It then stores the safe save and restore point into the MachineFrameInfo
attached to the MachineFunction.
This information is then used by the PrologEpilogInserter (PEI) to place the
related code at the right place. This pass runs right before the PEI.

Unlike the original paper of Chow from PLDI’88, this implementation of
shrink-wrapping does not use expensive data-flow analysis and does not need hack
to properly avoid frequently executed point. Instead, it relies on dominance and
loop properties.

The pass is off by default and each target can opt-in by setting the
EnableShrinkWrap boolean to true in their derived class of TargetPassConfig.
This setting can also be overwritten on the command line by using
-enable-shrink-wrap.

Before you try out the pass for your target, make sure you properly fix your
emitProlog/emitEpilog/adjustForXXX method to cope with basic blocks that are not
necessarily the entry block.

** Design Decisions **

1. ShrinkWrap is its own pass right now. It could frankly be merged into PEI but
for debugging and clarity I thought it was best to have its own file.
2. Right now, we only support one save point and one restore point. At some
point we can expand this to several save point and restore point, the impacted
component would then be:
- The pass itself: New algorithm needed.
- MachineFrameInfo: Hold a list or set of Save/Restore point instead of one
  pointer.
- PEI: Should loop over the save point and restore point.
Anyhow, at least for this first iteration, I do not believe this is interesting
to support the complex cases. We should revisit that when we motivating
examples.

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

<rdar://problem/3201744>

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

[Orc] Reapply r236465 with fixes for the MSVC bots.

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