fixed test to specify triple rather than arch and CPU

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

LTO: Cleanup parameter names and header docs, NFC

Follow LLVM style for the parameter names (`CamelCase` not `camelCase`),
and surface the header docs in doxygen.  No functionality change
intended.

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

[DAGCombine] Fixup SETCC legality checking

SETCC is one of those special node types for which operation actions (legality,
etc.) is keyed off of an operand type, not the node's value type. This makes
sense because the value type of a legal SETCC node is determined by its
operands' value type (via the TLI function getSetCCResultType). When the
SDAGBuilder creates SETCC nodes, it either creates them with an MVT::i1 value
type, or directly with the value type provided by TLI.getSetCCResultType.

The first problem being fixed here is that DAGCombine had several places
querying TLI.isOperationLegal on SETCC, but providing the return of
getSetCCResultType, instead of the operand type directly. This does not mean
what the author thought, and "luckily", most in-tree targets have SETCC with
Custom lowering, instead of marking them Legal, so these checks return false
anyway.

The second problem being fixed here is that two of the DAGCombines could create
SETCC nodes with arbitrary (integer) value types; specifically, those that
would simplify:

  (setcc a, b, op1) and|or (setcc a, b, op2) -> setcc a, b, op3
     (which is possible for some combinations of (op1, op2))

If the operands of the and|or node are actual setcc nodes, then this is not an
issue (because the and|or must share the same type), but, the relevant code in
DAGCombiner::visitANDLike and DAGCombiner::visitORLike actually calls
DAGCombiner::isSetCCEquivalent on each operand, and that function will
recognise setcc-like select_cc nodes with other return types. And, thus, when
creating new SETCC nodes, we need to be careful to respect the value-type
constraint. This is even true before type legalization, because it is quite
possible for the SELECT_CC node to have a legal type that does not happen to
match the corresponding TLI.getSetCCResultType type.

To be explicit, there is nothing that later fixes the value types of SETCC
nodes (if the type is legal, but does not happen to match
TLI.getSetCCResultType). Creating SETCCs with an MVT::i1 value type seems to
work only because, either MVT::i1 is not legal, or it is what
TLI.getSetCCResultType returns if it is legal. Fixing that is a larger change,
however. For the time being, restrict the relevant transformations to produce
only SETCC nodes with a value type matching TLI.getSetCCResultType (or MVT::i1
prior to type legalization).

Fixes PR24636.

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

don't set a legal vector type if we know we can't use that type (NFCI)

Added benefit: the 'if' logic now matches the text of the comment that describes it.

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

[BasicAA] Fix the handling of sext and zext in the analysis of GEPs.
Hopefully this will end the GEPs saga!

This commit reverts r245394, i.e., it reapplies r221876 while incorporating the
fixes from D11847.
r221876 was not reapplied alone because it was not safe and D11847 was not
applied alone because it needs r221876 to produce correct results.

This should fix PR24596.

Original commit message for r221876:
Let's try this again...

This reverts r219432, plus a bug fix.

Description of the bug in r219432 (by Nick):

The bug was using AllPositive to break out of the loop; if the loop break
condition i != e is changed to i != e && AllPositive then the
test_modulo_analysis_with_global test I've added will fail as the Modulo will
be calculated incorrectly (as the last loop iteration is skipped, so Modulo
isn't updated with its Scale).

Nick also adds this comment:

ComputeSignBit is safe to use in loops as it takes into account phi nodes, and
the  == EK_ZeroEx check is safe in loops as, no matter how the variable changes
between iterations, zero-extensions will always guarantee a zero sign bit. The
isValueEqualInPotentialCycles check is therefore definitely not needed as all
the variable analysis holds no matter how the variables change between loop
iterations.

And this patch also adds another enhancement to GetLinearExpression - basically
to convert ConstantInts to Offsets (see test_const_eval and
test_const_eval_scaled for the situations this improves).

Original commit message:

This reverts r218944, which reverted r218714, plus a bug fix.

Description of the bug in r218714 (by Nick):

The original patch forgot to check if the Scale in VariableGEPIndex flipped the
sign of the variable. The BasicAA pass iterates over the instructions in the
order they appear in the function, and so BasicAliasAnalysis::aliasGEP is
called with the variable it first comes across as parameter GEP1. Adding a
%reorder label puts the definition of %a after %b so aliasGEP is called with %b
as the first parameter and %a as the second. aliasGEP later calculates that %a
== %b + 1 - %idxprom where %idxprom >= 0 (if %a was passed as the first
parameter it would calculate %b == %a - 1 + %idxprom where %idxprom >= 0) -
ignoring that %idxprom is scaled by -1 here lead the patch to incorrectly
conclude that %a > %b.

Revised patch by Nick White, thanks! Thanks to Lang to isolating the bug.
Slightly modified by me to add an early exit from the loop and avoid
unnecessary, but expensive, function calls.

Original commit message:

Two related things:

1. Fixes a bug when calculating the offset in GetLinearExpression. The code
   previously used zext to extend the offset, so negative offsets were converted
   to large positive ones.

2. Enhance aliasGEP to deduce that, if the difference between two GEP
   allocations is positive and all the variables that govern the offset are also
   positive (i.e. the offset is strictly after the higher base pointer), then
   locations that fit in the gap between the two base pointers are NoAlias.

Patch by Nick White!

Message from D11847:
Un-revert of r241981 and fix for PR23626. The 'Or' case of GetLinearExpression
delegates to 'Add' if possible, and if not it returns an Opaque value.
Unfortunately the Scale and Offsets weren't being set (and so defaulted to 0) -
and a scale of zero effectively removes the variable from the GEP instruction.
This meant that BasicAA would return MustAliases when it should have been
returning PartialAliases (and PR23626 was an example of the GVN pass using an
incorrect MustAlias to merge loads from what should have been different
pointers).

Differential Revision: http://reviews.llvm.org/D11847
Patch by Nick White <n.j.white@gmail.com>!

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

WebAssembly: generate load/store

Summary: This handles all load/store operations that WebAssembly defines, and handles those necessary for C++ such as i1. I left a FIXME for outstanding features which aren't required for now.

Reviewers: sunfish

Subscribers: jfb, llvm-commits, dschuff

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

Infrastructure changes for Clang r246497.

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

generalize helper function of MergeConsecutiveStores to handle vector types (NFCI)

This was part of D7208 (r227242), but that commit was reverted because it exposed
a bug in AArch64 lowering. I should have that fixed and the rest of the commit
reinstated soon.

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

Revert "[lit] Speculatively fix PR24554 by manually closing the process handle"

This reverts commit r245946. It didn't help the problem:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/9179/steps/run%20tests/logs/stdio
LINK : fatal error LNK1104: cannot open file

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

Fix bug in method LLLexer::FP80HexToIntPair

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

Fix Windows build by including raw_ostream.h

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

Fix CHECK directives that weren't checking.

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

Rollback of commit "Repress sanitization on User dtor."
This would have suppressed bug 24578, about use-after-
destroy on User and MDNode. Rolled back suppression for
the sake of code cleanliness, in preferance for bug
tracking to keep track of this issue.

This reverts commit 6ff2baabc4625d5b0a8dccf76aa0f72d930ea6c0.

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

[DAGCombine] Use getSetCCResultType utility function

DAGCombine has a utility wrapper around TLI's getSetCCResultType; use it in the
one place in DAGCombine still directly calling the TLI function. NFC.

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

[x86] enable machine combiner reassociations for scalar 'or' insts

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

[EH] Handle non-Function personalities like unknown personalities

Also delete and simplify a lot of MachineModuleInfo code that used to be
needed to handle personalities on landingpads.  Now that the personality
is on the LLVM Function, we no longer need to track it this way on MMI.
Certainly it should not live on LandingPadInfo.

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

[FunctionAttr] Infer nonnull attributes on returns

Teach FunctionAttr to infer the nonnull attribute on return values of functions which never return a potentially null value. This is done both via a conservative local analysis for the function itself and a optimistic per-SCC analysis. If no function in the SCC returns anything which could be null (other than values from other functions in the SCC), we can conclude no function returned a null pointer. Even if some function within the SCC returns a null pointer, we may be able to locally conclude that some don't.

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

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

[llvm-readobj] Dump MachO Dysymtab command.

Example output:

File: <stdin>
Format: Mach-O 64-bit x86-64
Arch: x86_64
AddressSize: 64bit
Dysymtab {

ilocalsym: 0
nlocalsym: 6
iextdefsym: 6
nextdefsym: 2
iundefsym: 8
nundefsym: 0
tocoff: 0
ntoc: 0
modtaboff: 0
nmodtab: 0
extrefsymoff: 0
nextrefsyms: 0
indirectsymoff: 0
nindirectsyms: 0
extreloff: 0
nextrel: 0
locreloff: 0
nlocrel: 0

}

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

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

[AArch64][CollectLOH] Remove an invalid assertion and add a test case exposing it.

rdar://problem/22491525

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

[libFuzzer] update the docs to mention llvm-as-fuzzer

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

Undo reversion on commit: Revert "Revert "Repress sanitization on User dtor.
Modify msan macros for applying attribute""

This reverts commit 020e70a79878c96457e6882bcdfaf6628baf32b7.

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

[DAGCombine] Remove some old dead code for forming SETCC nodes

This code was dead when it was committed in r23665 (Oct 7, 2005), and before it
reaches its 10th anniversary, it really should go. We can always bring it back
if we'd like, but it forms more SETCC nodes, and the way we do legality
checking on SETCC nodes is wrong in a number of places, and removing this means
fewer places to fix. NFC.

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

[LazyValueInfo] Look through Phi nodes when trying to prove a predicate

If asked to prove a predicate about a value produced by a PHI node, LazyValueInfo was unable to do so even if the predicate was known to be true for each input to the PHI. This prevented JumpThreading from eliminating a provably redundant branch.

The problematic test case looks something like this:
ListNode *p = ...;
while (p != null) {
  if (!p) return;
  x = g->x; // unrelated
  p = p->next
}

The null check at the top of the loop is redundant since the value of 'p' is null checked on entry to the loop and before executing the backedge. This resulted in us a) executing an extra null check per iteration and b) not being able to LICM unrelated loads after the check since we couldn't prove they would execute or that their dereferenceability wasn't effected by the null check on the first iteration.

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

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

Rework of the new interface for shrink wrapping

Based on comments from Hal
(http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150810/292978.html),
I've changed the interface to add a callback mechanism to the
TargetFrameLowering class to query whether the specific target
supports shrink wrapping.  By default, shrink wrapping is disabled by
default. Each target can override the default behaviour using the
TargetFrameLowering::targetSupportsShrinkWrapping() method. Shrink
wrapping can still be explicitly enabled or disabled from the command
line, using the existing -enable-shrink-wrap=<true|false> option.

Phabricator: http://reviews.llvm.org/D12293

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

AArch64: Fix loads to lower NEON vector lanes using GPR registers

The ISelLowering code turned insertion turned the element for the
lowest lane of a BUILD_VECTOR into an INSERT_SUBREG, this prohibited
the patterns for SCALAR_TO_VECTOR(Load) to match later. Restrict this
to cases without a load argument.

Reported in rdar://22223823

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

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

X86: Fix FastISel SSESelect register class

X86FastISel has been using the wrong register class for VBLENDVPS which
produces a VR128 and needs an extra copy to the target register. The
problem was already hit by the existing test cases when using
> llvm-lit -Dllc="llc -verify-machineinstr"

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

[BitcodeReader] Ensure we can read constant vector selects with an i1 condition

Summary:
Constant vectors weren't allowed to have an i1 condition in the
BitcodeReader. Make sure we have the same restrictions that are
documented, not more.

Reviewers: nlewycky, rafael, kschimpf

Subscribers: llvm-commits

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

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

Build a lib/Fuzzer version for llvm-as.

Summary:
This CL is associated with a fuzzing effort to find bugs in LLVM. The
first step is to fuzz llvm-as to find potential issues in generating
IR. Both afl-fuzz and LLVM's lib/Fuzzer are being used.

This CL introduces the executable that implements the in-process
fuzzer using LLVM's lib/Fuzzer. The motivation for using lib/Fuzzer is
based on time comparisons between afl-fuzz and lib/Fuzzer. Early
results show that per-process, the lib/Fuzzer implemenation of llvm-as
(i.e. this CL) generates over 30 times the number of mutations found
by afl-fuzz, per hour runtime. The speedup is due to the removal of
overhead of forking a process, and loading the executable into memory.

I placed this under the tools directory, since it is an executable. It
is also only conditionally built if (using cmake) the flag
LLVM_USEE_SANITIZE_COVERAGE is used, so that it isn't built by
default.

Reviewers: kcc, filcab

Subscribers: llvm-commits

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

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

[MC/AsmParser] Avoid setting MCSymbol.IsUsed in some cases

Avoid marking some MCSymbols as used in MC/AsmParser.cpp when no uses
exist. This fixes a bug in parseAssignmentExpression() which
inadvertently sets IsUsed, thereby triggering:

    "invalid re-assignment of non-absolute variable"

on otherwise valid code. No other functionality change intended.

The original version of this patch touched many calls to MCSymbol
accessors. On rafael's advice, I have stripped this patch down a bit.

As a follow-up, I intend to find the call sites which intentionally set
IsUsed and force them to do so explicitly.

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

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

[llvm-readobj] Add pair of missing braces.

This fixes a regression introduced in r246151.

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

Change comment to verify commit accesss.

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

Revert "Repress sanitization on User dtor. Modify msan macros for applying attribute"

This reverts commit 5e3bfbb38eb3fb6f568b107f6b239e0aa4c5f334.

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

Repress sanitization on User dtor. Modify msan macros for applying attribute
to repress sanitization. Move attribute for repressing sanitization to
operator delete for User, MDNode.

Summary: In response to bug 24578, reported against failing LLVM test.

Reviewers: chandlerc, rsmith, eugenis

Subscribers: llvm-commits

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

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

[SectionMemoryManager] Use range-based for loops. No functional change intended.

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

AVX512: ktest implemantation
Added tests for encoding.

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

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

AVX512: Implemented encoding and intrinsics for vdbpsadbw
Added tests for intrinsics and encoding.

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

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

AVX512: kadd implementation
Added tests for encoding.

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

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

AVX512: Add encoding tests for vscatter instructions

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

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

AVX512: Implemented encoding and intrinsics for vpalignr
Added tests for intrinsics and encoding.

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

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

[AggressiveAntiDepBreaker] Check for EarlyClobber on defining instruction

AggressiveAntiDepBreaker was doing some EarlyClobber checking, but was not
checking that the register being potentially renamed was defined by an
early-clobber def where there was also a use, in that instruction, of the
register being considered as the target of the rename. Fixes PR24014.

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

Force the locale when executing ld gold

Summary:
If run with other locales (like French),
the decode operation might fail

Reviewers: rafael

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

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

[JumpThreading] make jump threading respect convergent annotation.

Summary:
JumpThreading shouldn't duplicate a convergent call, because that would move a convergent call into a control-inequivalent location. For example,
  if (cond) {
    ...
  } else {
    ...
  }
  convergent_call();
  if (cond) {
    ...
  } else {
    ...
  }
should not be optimized to
  if (cond) {
    ...
    convergent_call();
    ...
  } else {
    ...
    convergent_call();
    ...
  }

Test Plan: test/Transforms/JumpThreading/basic.ll

Patch by Xuetian Weng.

Reviewers: resistor, arsenm, jingyue

Subscribers: llvm-commits

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

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

[dsymutil] Do not mistakenly reuse the current object file when the next one isn't found.

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

[dsymutil] Fix testcase.

This testcase required 2 copies of the same file, and the second
copy was missing. It was currently working because of a bug I'm
about to fix.

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

[dsymutil] Do not crash on empty debug_range range.

The fix is trivial (The actual patch is 2 lines, but as it changes
indentation it looks like more).
clang does not produce this kind of (slightly bogus) debug info
anymore, thus I had to rely on a hand-crafted assembly test to trigger
that case.

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

[dsymutil] Fix caching of current range. NFC.

The current range cache will will just be hit more often, no
visible external change.

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

[dsymutil] Fix handling of inlined_subprogram low_pcs

The value of an inlined subprogram low_pc attribute should not
get relocated, but it can happen that it matches the enclosing
function's start address and thus gets the generic treatment.
Special case it to avoid applying the PC offset twice.

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

[dsymutil] Do not construct a StringRef from a std::string temporary

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

[dsymutil] Implement -symtab/-s option.

This option dumps the STAB entries that define the debug map(s)
stored in the input binaries, and then exits.

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

Support: Support LLVM_ENABLE_THREADS=0 in llvm/Support/thread.h.

Specifically, the header now provides llvm::thread, which is either a
typedef of std::thread or a replacement that calls the function synchronously
depending on the value of LLVM_ENABLE_THREADS.

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

[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands

There were really two problems here. The first was that we had the truth tables
for signed i1 comparisons backward. I imagine these are not very common, but if
you have:
  setcc i1 x, y, LT
this has the '0 1' and the '1 0' results flipped compared to:
  setcc i1 x, y, ULT
because, in the signed case, '1 0' is really '-1 0', and the answer is not the
same as in the unsigned case.

The second problem was that we did not have patterns (at all) for the unsigned
comparisons select_cc nodes for i1 comparison operands. This was the specific
cause of PR24552. These had to be added (and a missing Altivec promotion added
as well) to make sure these function for all types. I've added a bunch more
test cases for these patterns, and there are a few FIXMEs in the test case
regarding code-quality.

Fixes PR24552.

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

NFC: Code style in VectorUtils.cpp

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

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

Revert "Revert "New interface function is added to VectorUtils Value *getSplatValue(Value *Val);""

This reverts commit r246379. It seems that the commit was not the culprit,
and the bot will be investigated for instability.

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

Revert "New interface function is added to VectorUtils Value *getSplatValue(Value *Val);"

This reverts commit r246371, as it cause a rather obscure bug in AArch64
test-suite paq8p (time outs, seg-faults). I'll investigate it before
reapplying.

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

Stop calling the flat out insane ARM target parsing code unless the
architecture string is something quite weird. Similarly delay calling
the BPF parsing code, although that is more reasonable.

To understand why I was motivated to make this change, it cuts the time
for running the ADT TripleTest unittests by a factor of two in
non-optimized builds (the developer default) and reduces my 'check-llvm'
time by a full 15 seconds. The implementation of parseARMArch is *that*
slow. I tried to fix it in the prior series of commits, but frankly,
I have no idea how to finish fixing it. The entire premise of the
function (to allow 'v7a-unknown-linux' or some such to parse as an
'arm-unknown-linux' triple) seems completely insane to me, but I'll let
the ARM folks sort that out. At least it is now out of the critical path
of every developer working on LLVM. It also will likely make some other
folks' code significantly faster as I've heard reports of 2% of time
spent in triple parsing even in optimized builds!

I'm not done making this code faster, but I am done trying to improve
the ARM target parsing code.

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

Remove a linear walk to find the default FPU for a given CPU by directly
expanding the .def file within a StringSwitch.

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

[MIR Serialization] static -> static const in getSerializable*MachineOperandTargetFlags

Make the arrays 'static const' instead of just 'static'. Post-commit review
comment from Roman Divacky on IRC. NFC.

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

Teach the target parsing framework to directly compute the length of all
of its strings when expanding the string literals from the macros, and
push all of the APIs to be StringRef instead of C-string APIs.

This (remarkably) removes a very non-trivial number of strlen calls. It
even deletes code and complexity from one of the primary users -- Clang.

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

[PowerPC/MIR Serialization] Target flags serialization support

Add support for MIR serialization of PowerPC-specific operand target flags
(based on the generic infrastructure added in r244185 and r245383).

I won't even pretend that this is good test coverage, but this includes the
regression test associated with r246372. Adding an MIR test for that fix is far
superior to adding an IR-level test because particular instruction-scheduling
decisions are necessary in order to expose the bug, and using an MIR test we
can start the pipeline post-scheduling.

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

[PowerPC] Don't assume ADDISdtprelHA's source is r3

Even through ADDISdtprelHA generally has r3 as its source register, it is
possible for the instruction scheduler to move things around such that some
other register is the source. We need to print the actual source register, not
always r3. Fixes PR24394.

The test case will come in a follow-up commit because it depends on MIR
target-flags parsing.

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

New interface function is added to VectorUtils
Value *getSplatValue(Value *Val);

It complements the CreateVectorSplat(), which creates 2 instructions - insertelement and shuffle with all-zero mask.

The new function recognizes the pattern - insertelement+shuffle and returns the splat value (or nullptr).
It also returns a splat value form ConstantDataVector, for completeness.

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

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

Refactor the ARM target parsing to use a def file with macros to expand
the necessary tables.

This will allow me to restructure the code and structures using this to
be significantly more efficient. It also removes the duplication of the
list of several enumerators. It also enshrines that the order of
enumerators match the order of the entries in the tables, something the
implementation code actually uses.

No functionality changed (yet).

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

[Triple] Use clang-format to normalize the formatting of the ARM target
parsing logic prior to making substantial changes to it.

This parsing logic is incredibly wasteful, so I'm planning to rewrite
it. Just unittesting the triple parsing logic spends well over 80% of
its time in the ARM parsing logic, and others have measured significant
time spent here in real production compiles.

Stay tuned...

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

[Triple] Stop abusing a class to have only static methods and just use
the namespace that we are already using for the enums that are produced
by the parsing.

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

SelectionDAG: add missing ComputeSignBits case for SELECT_CC

Identical to SELECT, just with different operand numbers.

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

Fix shared library build.

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

[ARM] Fix up buildbots after r246360

I have no idea how I missed this in my internal testing. Just no idea. Sorry for the bot-armageddon.

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

[ARM] Hoist fabs/fneg above a conversion to float.

This is especially visible in softfp mode, for example in the implementation of libm fabs/fneg functions. If we have:

%1 = vmovdrr r0, r1
%2 = fabs %1

then move the fabs before the vmovdrr:

%1 = and r1, #0x7FFFFFFF
%2 = vmovdrr r0, r1

This is never a lose, and could be a serious win because the vmovdrr may be followed by a vmovrrd, which would enable us to remove the conversion into FPRs completely.

We already do this for f32, but not for f64. Tests are added for both.

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

AMDGPU: Add sdst operand to VOP2b instructions

The VOP3 encoding of these allows any SGPR pair for the i1
output, but this was forced before to always use vcc.
This doesn't yet try to use this, but does add the operand
to the definitions so the main change is adding vcc to the
output of the VOP2 encoding.

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

AMDGPU: Set mem operands for spill instructions

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

AMDGPU: Fix dropping mem operands when moving to VALU

Without a memory operand, mayLoad or mayStore instructions
are treated as hasUnorderedMemRef, which results in much worse
scheduling.

We really should have a verifier check that any
non-side effecting mayLoad or mayStore has a memory operand.
There are a few instructions (interp and images) which I'm
not sure what / where to add these.

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

AMDGPU/SI: Fix some invaild assumptions when folding 64-bit immediates

Summary:
We were assuming tha if the use operand had a sub-register that
the immediate was 64-bits, but this was breaking the case of
folding a 64-bit immediate into another 64-bit instruction.

Reviewers: arsenm

Subscribers: arsenm, llvm-commits

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

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

AMDGPU/SI: Factor operand folding code into its own function

Reviewers: arsenm

Subscribers: arsenm, llvm-commits

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

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

Revert r246350, "The host and default target triples do not need to match for "native""

Wrong assumption. Consider --host=x86_64-linux --target=(i686|x86_64)-win32. See also r193459.

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

DI: Update tests before adding !dbg subprogram attachments

I'm working on adding !dbg attachments to functions (PR23367), which
we'll use to determine the canonical subprogram for a function (instead
of the `subprograms:` array in the compile units).  This updates a few
old tests in preparation.

Transforms/Mem2Reg/ConvertDebugInfo2.ll had an old-style grep+count
based test that would start to fail because I've added an extra line
with `!dbg`.  Instead, explicitly `CHECK` for what I think the test
actually cares about.

All three testcases have subprograms with a valid `function:` reference
-- which means my upgrade script will add a `!dbg` attachment -- but
that aren't referenced from any compile unit.  I suspect these testcases
were handreduced over-zealously (or have bitrotted?).  Add a reference
from the compile unit so that upcoming Verifier checks won't fail here.

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

The host and default target triples do not need to match for "native"
backend to work.

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

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

DI: Set DILexicalBlock columns >= 65536 to 0/unknown

This fixes PR24621 and matches what we do for `DILocation`.  Although
the limit seems somewhat artificial, there are places in the backend
that also assume 16-bit columns, so we may as well just be consistent
about the limits.

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

Use UNSUPPORTED instead of XFAIL to disable this test, as it passes on one AArch64 bot.

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

lit: Match UNSUPPORTED against target triple as we do for XFAIL.

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

[X86] NFC: Clean up and clang-format a few lines

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

DI: Add Function::getSubprogram()

Add `Function::setSubprogram()` and `Function::getSubprogram()`,
convenience methods to forward to `setMetadata()` and `getMetadata()`,
respectively, and deal in `DISubprogram` instead of `MDNode`.

Also add a verifier check to enforce that `!dbg` attachments are always
subprograms.

Originally (when I had the llvm-dev discussion back in April) I thought
I'd store a pointer directly on `llvm::Function` for these attachments
-- we frequently have debug info, and that's much cheaper than using map
in the context if there are no other function-level attachments -- but
for now I'm just using the generic infrastructure.  Let's add the extra
complexity only if this shows up in a profile.

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

AsmPrinter: Allow null subroutine type

Currently the DWARF backend requires that subprograms have a type, and
the type is ignored if it has an empty type array.  The long term
direction here -- see PR23079 -- is instead to skip the type entirely if
there's no valid type.

It turns out we have cases in tree of missing types on subprograms, but
since they're not referenced by compile units, the backend never crashes
on them.  One option would be to add a Verifier check that subprograms
have types, and fix the bitrot.  However, this is a fair bit of churn
(20-30 testcases) that would be reversed anyway by PR23079.

I found this inconsistency because of a WIP patch and upgrade script for
PR23367 that started crashing on test/DebugInfo/2010-10-01-crash.ll.
This commit updates the testcase to reference the subprogram from the
compile unit, and fixes the resulting crash (in line with the direction
of PR23079).  This also updates `DIBuilder` to stop assuming a non-null
pointer for the subroutine types.

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

Revert r246232 and r246304.

This reverts isSafeToSpeculativelyExecute's use of ReadNone until we
split ReadNone into two pieces: one attribute which reasons about how
the function reasons about memory and another attribute which determines
how it may be speculated, CSE'd, trap, etc.

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

Remove white space (test commit)

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

Split the gold tests into X86 and PowerPC directories.

Patch by Than McIntosh!

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

DI: Require subprogram definitions to be distinct

As a follow-up to r246098, require `DISubprogram` definitions
(`isDefinition: true`) to be 'distinct'.  Specifically, add an assembler
check, a verifier check, and bitcode upgrading logic to combat testcase
bitrot after the `DIBuilder` change.

While working on the testcases, I realized that
test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore.  Its
purpose was to check for a corner case in PR22792 where two subprogram
definitions match exactly and share the same metadata node.  The new
verifier check, requiring that subprogram definitions are 'distinct',
precludes that possibility.

I updated almost all the IR with the following script:

    git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' |
    grep -v test/Bitcode |
    xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/'

Likely some variant of would work for out-of-tree testcases.

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

[IR] Add some asserts to CallInst and InvokeInst; NFCI.

The asserts check that accessors supposed to access call / invoke
arguments only ever access call / invoke arguments.

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

[InstCombine] Fix PR24605.

PR24605 is caused due to an incorrect insert point in instcombine's IR
builder.  When simplifying

  %t = add X Y
  ...
  %m = icmp ... %t

the replacement for %t should be placed before %t, not before %m, as
there could be a use of %t between %t and %m.

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

Optimize memcmp(x,y,n)==0 for small n and suitably aligned x/y.

http://reviews.llvm.org/D6952
PR20673

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

[test] (NFC) Simplify Transforms/ConstProp/calls.ll

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

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

[mips64][mcjit] Add N64R6 relocations tests and fix N64R2 tests

This patch adds a test for MIPS64R6 relocations, it corrects check
expressions for R_MIPS_26 and R_MIPS_PC16 relocations in MIPS64R2 test, and
it adds run for big endian in MIPS64R2 test.

Patch by Vladimir Radosavljevic.

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

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

[mips] Remove incorrect DebugLoc entries from prologue

This has been causing the prologue_end to be incorrectly positioned.

Patch by Vladimir Radosavljevic.

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

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

Make MergeConsecutiveStores look at other stores on same chain

When combiner AA is enabled, look at stores on the same chain.
Non-aliasing stores are moved to the same chain so the existing
code fails because it expects to find an adajcent store on a consecutive
chain.

Because of how DAGCombiner tries these store combines,
MergeConsecutiveStores doesn't see the correct set of stores on the chain
when it visits the other stores. Each store individually has its chain
fixed before trying to merge consecutive stores, and then tries to merge
stores from that point before the other stores have been processed to
have their chains fixed. To fix this, attempt to use FindBetterChain
on any possibly neighboring stores in visitSTORE.

Suppose you have 4 32-bit stores that should be merged into 1 vector
store. One store would be visited first, fixing the chain. What happens is
because not all of the store chains have yet been fixed, 2 of the stores
are merged. The other 2 stores later have their chains fixed,
but because the other stores were already merged, they have different
memory types and merging the two different sized stores is not
supported and would be more difficult to handle.

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

Test case for r246304.

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

Remove Merge Functions pointer comparisons

Summary:
This patch removes two remaining places where pointer value comparisons
are used to order functions: comparing range annotation metadata, and comparing
block address constants. (These are both rare cases, and so no actual
non-determinism was observed from either case).

The fix for range metadata is simple: the annotation always consists of a pair
of integers, so we just order by those integers.

The fix for block addresses is more subtle. Two constants are the same if they
are the same basic block in the same function, or if they refer to corresponding
basic blocks in each respective function. Note that in the first case, merging
is trivially correct. In the second, the correctness of merging relies on the
fact that the the values of block addresses cannot be compared. This change is
actually an enhancement, as these functions could not previously be merged (see
merge-block-address.ll).

There is still a problem with cross function block addresses, in that constants
pointing to a basic block in a merged function is not updated.

This also more robustly compares floating point constants by all fields of their
semantics, and fixes a dyn_cast/cast mixup.

Author: jrkoenig
Reviewers: dschuff, nlewycky, jfb
Subscribers llvm-commits
Differential revision: http://reviews.llvm.org/D12376

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

[CodeGen] isInTailCallPosition didn't consider readnone tailcalls

A readnone tailcall may still have a chain of computation which follows
it that would invalidate a tailcall lowering.  Don't skip the analysis
in such cases.

This fixes PR24613.

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

[LoopUtils] Move a private constructor nearer the other private members

This was part of Adam Nemet's review feedback that I forgot to implement.

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

[x86] enable machine combiner reassociations for scalar 'and' insts

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

[MC] Convert tests to use llvm-readobj --macho-version-min.

As an added bonus this also tests the newly introduced feature.

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

llvm-readobj: Dump more info for COFF import libraries.

This patch teaches llvm-readobj to print out COFF import file header fields.

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