[HotColdSplitting] Refine definition of unlikelyExecuted

The splitting pass uses its 'unlikelyExecuted' predicate to statically
decide which blocks are cold.

- Do not treat noreturn calls as if they are cold unless they are actually
  marked cold. This is motivated by functions like exit() and longjmp(), which
  are not beneficial to outline.

- Do not treat inline asm as an outlining barrier. In practice asm("") is
  frequently used to inhibit basic block merging; enabling outlining in this case
  results in substantial memory savings.

- Treat invokes of cold functions as cold.

As a drive-by, remove the 'exceptionHandlingFunctions' predicate, because it's
no longer needed. The pass can identify & outline blocks dominated by EH pads,
so there's no need to special-case __cxa_begin_catch etc.

Differential Revision: https://reviews.llvm.org/D54244

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

[HotColdSplitting] Outline more than once per function

Algorithm: Identify maximal cold regions and put them in a worklist. If
a candidate region overlaps with another, discard it. While the worklist
is full, remove a single-entry sub-region from the worklist and attempt
to outline it. By the non-overlap property, this should not invalidate
parts of the domtree pertaining to other outlining regions.

Testing: LNT results on X86 are clean. With test-suite + externals, llvm
outlines 134KB pre-patch, and 352KB post-patch (+ ~2.6x). The file
483.xalancbmk/src/Constants.cpp stands out as an extreme case where llvm
outlines over 100 times in some functions (mostly EH paths). There was
not a significant performance impact pre vs. post-patch.

Differential Revision: https://reviews.llvm.org/D53887

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

Update the Swift version numbers reported by objdump

Summary:
Add Swift 4.1, Swift 4.2, and Swift 5 version numbers to objdump's
MachODump's print_imae_info routines.

rdar://46548425

Reviewers: pete, lhames, bob.wilson

Reviewed By: pete, bob.wilson

Subscribers: bob.wilson, llvm-commits

Differential Revision: https://reviews.llvm.org/D55442

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

[NativePDB] Reconstruct function declarations from debug info.

Previously we would create an lldb::Function object for each function
parsed, but we would not add these to the clang AST. This is a first
step towards getting local variable support working, as we first need an
AST decl so that when we create local variable entries, they have the
proper DeclContext.

Differential Revision: https://reviews.llvm.org/D55384

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

[llvm-tapi] Don't try to override SequenceTraits for std::string

For some reason this doesn't seem to work with LLVM_LINK_LLVM_DYLIB
build.

See https://logs.chromium.org/logs/chromium/bb/client.wasm.llvm/linux/37764/+/recipes/steps/LLVM_regression_tests/0/stdout

What is more it seems that overriding these traits for core types
(including std::string) is not supported/recommend by YAMLTraits.h.
See line 1918 which has the assertion:
 "only use LLVM_YAML_IS_SEQUENCE_VECTOR for types you control"

Differential Revision: https://reviews.llvm.org/D55381

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

[DAGCombiner] split trunc from extend in hoistLogicOpWithSameOpcodeHands; NFC

This duplicates several shared checks, but we need to split
this up to fix underlying bugs in smaller steps.

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

[X86] Replace instregex with instrs list. NFCI.

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

AMDGPU: Allow f32 types for llvm.amdgcn.s.buffer.load

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

[llvm-mca][x86] Add RDSEED instruction resource tests for GLM

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

[llvm-mca][x86] Add missing AES instruction resource tests

Add missing non-VEX instructions

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

[llvm-mca][x86] Add RDRAND/RDSEED instruction resource tests

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

[CostModel][X86] Fix overcounting arithmetic cost in illegal types in getArithmeticReductionCost/getMinMaxReductionCost

We were overcounting the number of arithmetic operations needed at each level before we reach a legal type. We were using the full vector type for that level, but we are going to split the input vector at that level in half. So the effective arithmetic operation cost at that level is half the width.

So for example on 8i32 on an sse target. Were were calculating the cost of an 8i32 op which is likely 2 for basic integer. Then after the loop we count 2 more v4i32 ops. For a total arith cost of 4. But if you look at the assembly there would only be 3 arithmetic ops.

There are still more bugs in this code that I'm going to work on next. The non pairwise code shouldn't count extract subvectors in the loop. There are no extracts, the types are split in registers. For pairwise we need to use 2 two src permute shuffles.

Differential Revision: https://reviews.llvm.org/D55397

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

[X86] Initialize and Register X86CondBrFoldingPass

To make X86CondBrFoldingPass can be run with --run-pass option, this can test one wrong assertion on analyzeCompare function for SUB32ri when its operand is not imm

Patch by Jianping Chen

Differential Revision: https://reviews.llvm.org/D55412

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

AMDGPU: Remove llvm.SI.tbuffer.store

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

[X86] Improve pfm counter coverage for llvm-exegesis

This patch attempts to improve pfm perf counter coverage for all the x86 CPUs that libpfm4 supports.

Intel/AMD CPU families tend to share names for cycle/uops counters so even if they don't have a scheduler model yet they can at least use the default values (checked against the libpfm4 source code).

The remaining CPUs (where their port/pipe resource counters are known) I've tried to add to the existing model mappings.

These are untested but don't represent a regression to current llvm-exegesis behaviour for these CPUs.

Differential Revision: https://reviews.llvm.org/D55432

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

AMDGPU: Remove llvm.SI.buffer.load.dword

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

AMDGPU: Remove llvm.AMDGPU.kill

This is the last of the old AMDGPU intrinsics.

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

[DAGCombiner] disable truncation of binops by default

As discussed in the post-commit thread of r347917, this
transform is fighting with an existing transform causing
an infinite loop or out-of-memory, so this is effectively
reverting r347917 and its follow-up r348195 while we
investigate the bug.

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

Reapply "[DemandedBits][BDCE] Support vectors of integers"

DemandedBits and BDCE currently only support scalar integers. This
patch extends them to also handle vector integer operations. In this
case bits are not tracked for individual vector elements, instead a
bit is demanded if it is demanded for any of the elements. This matches
the behavior of computeKnownBits in ValueTracking and
SimplifyDemandedBits in InstCombine.

Unlike the previous iteration of this patch, getDemandedBits() can now
again be called on arbirary (sized) instructions, even if they don't
have integer or vector of integer type. (For vector types the size of the
returned mask will now be the scalar size in bits though.)

The added LoopVectorize test case shows a case which triggered an
assertion failure with the previous attempt, because getDemandedBits()
was called on a pointer-typed instruction.

Differential Revision: https://reviews.llvm.org/D55297

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

[AMDGPU] Shrink scalar AND, OR, XOR instructions

This change attempts to shrink scalar AND, OR and XOR instructions which take an immediate that isn't inlineable.

It performs:
AND s0, s0, ~(1 << n) -> BITSET0 s0, n
OR s0, s0, (1 << n) -> BITSET1 s0, n
AND s0, s1, x -> ANDN2 s0, s1, ~x
OR s0, s1, x -> ORN2 s0, s1, ~x
XOR s0, s1, x -> XNOR s0, s1, ~x

In particular, this catches setting and clearing the sign bit for fabs (and x, 0x7ffffffff -> bitset0 x, 31 and or x, 0x80000000 -> bitset1 x, 31).

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

[DAGCombiner] remove explicit calls to AddToWorkList; NFCI

As noted in the post-commit thread for rL347917:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608936.html
...we don't need to repeat these calls because the combiner does it automatically.

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

Introduce llvm.experimental.widenable_condition intrinsic

This patch introduces a new instinsic `@llvm.experimental.widenable_condition`
that allows explicit representation for guards. It is an alternative to using
`@llvm.experimental.guard` intrinsic that does not contain implicit control flow.

We keep finding places where `@llvm.experimental.guard` is not supported or
treated too conservatively, and there are 2 reasons to that:

- `@llvm.experimental.guard` has memory write side effect to model implicit control flow,
  and this sometimes confuses passes and analyzes that work with memory;
- Not all passes and analysis are aware of the semantics of guards. These passes treat them
  as regular throwing call and have no idea that the condition of guard may be used to prove
  something. One well-known place which had caused us troubles in the past is explicit loop
  iteration count calculation in SCEV. Another example is new loop unswitching which is not
  aware of guards. Whenever a new pass appears, we potentially have this problem there.

Rather than go and fix all these places (and commit to keep track of them and add support
in future), it seems more reasonable to leverage the existing optimizer's logic as much as possible.
The only significant difference between guards and regular explicit branches is that guard's condition
can be widened. It means that a guard contains (explicitly or implicitly) a `deopt` block successor,
and it is always legal to go there no matter what the guard condition is. The other successor is
a guarded block, and it is only legal to go there if the condition is true.

This patch introduces a new explicit form of guards alternative to `@llvm.experimental.guard`
intrinsic. Now a widenable guard can be represented in the CFG explicitly like this:

    %widenable_condition = call i1 @llvm.experimental.widenable.condition()
    %new_condition = and i1 %cond, %widenable_condition
    br i1 %new_condition, label %guarded, label %deopt

  guarded:
    ; Guarded instructions

  deopt:
    call type @llvm.experimental.deoptimize(<args...>) [ "deopt"(<deopt_args...>) ]

The new intrinsic `@llvm.experimental.widenable.condition` has semantics of an
`undef`, but the intrinsic prevents the optimizer from folding it early. This form
should exploit all optimization boons provided to `br` instuction, and it still can be
widened by replacing the result of `@llvm.experimental.widenable.condition()`
with `and` with any arbitrary boolean value (as long as the branch that is taken when
it is `false` has a deopt and has no side-effects).

For more motivation, please check llvm-dev discussion "[llvm-dev] Giving up using
implicit control flow in guards".

This patch introduces this new intrinsic with respective LangRef changes and a pass
that converts old-style guards (expressed as intrinsics) into the new form.

The naming discussion is still ungoing. Merging this to unblock further items. We can
later change the name of this intrinsic.

Reviewed By: reames, fedor.sergeev, sanjoy
Differential Revision: https://reviews.llvm.org/D51207

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

ARM: use correct offset from base pointer (r6) in call frame regions.

When we had dynamic call frames (i.e. sp adjustment around each call) we
were including that adjustment into offsets calculated based on r6, even
though it's only sp that changes. This led to incorrect stack slot
accesses.

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

[Targets] Add errors for tiny and kernel codemodel on targets that don't support them

Adds fatal errors for any target that does not support the Tiny or Kernel
codemodels by rejigging the getEffectiveCodeModel calls.

Differential Revision: https://reviews.llvm.org/D50141

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

Fix gcc7.3 -Wparentheses warning. NFCI.

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

[yaml2obj] format some codes NFC.

Summary: This line is longer than 80 characters.

Subscribers: llvm-commits, jakehehrlich

Differential Revision: https://reviews.llvm.org/D55419

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

[yaml2obj] revert bad change

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

[yaml2obj] format some codes NFC.

Summary: This line is longer than 80 characters.

Subscribers: llvm-commits, jakehehrlich

Differential Revision: https://reviews.llvm.org/D55419

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

Fix test/tools/llvm-mca/AArch64/Exynos/direct-branch.s on Mac

It was failing as below. Adding a triple seems to help.

--
: 'RUN: at line 2';   /work/llvm.combined/build.release/bin/llvm-mca -march=aarch64 -mcpu=exynos-m1 -resource-pressure=false < /work/llvm.combined/llvm/test/tools/llvm-mca/AArch64/Exynos/direct-branch.s | /work/llvm.combined/build.release/bin/FileCheck /work/llvm.combined/llvm/test/tools/llvm-mca/AArch64/Exynos/direct-branch.s -check-prefixes=ALL,M1
: 'RUN: at line 3';   /work/llvm.combined/build.release/bin/llvm-mca -march=aarch64 -mcpu=exynos-m3 -resource-pressure=false < /work/llvm.combined/llvm/test/tools/llvm-mca/AArch64/Exynos/direct-branch.s | /work/llvm.combined/build.release/bin/FileCheck /work/llvm.combined/llvm/test/tools/llvm-mca/AArch64/Exynos/direct-branch.s -check-prefixes=ALL,M3
--
Exit Code: 1

Command Output (stderr):
--
/work/llvm.combined/llvm/test/tools/llvm-mca/AArch64/Exynos/direct-branch.s:36:12: error: M1-NEXT: expected string not found in input
           ^
<stdin>:21:2: note: scanning from here
 1 0 0.25 b Ltmp0
 ^

--

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

[utils] Use operator "in" instead of bound function "has_key"

has_key has been removed in Python 3. The in comparison operator can be used
instead.

Differential Revision: https://reviews.llvm.org/D55310

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

[X86] Add ivybridge to llvm-exegesis PFM counter mappings

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

[SelectionDAG] Don't pass on DemandedElts when handling SCALAR_TO_VECTOR

Fixes an assertion:

llc: lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2200: llvm::KnownBits llvm::SelectionDAG::computeKnownBits(llvm::SDValue, const llvm::APInt&, unsigned int) const: Assertion `(!Op.getValueType().isVector() || NumElts == Op.getValueType().getVectorNumElements()) && "Unexpected vector size"' failed.

Committed on behalf of: @pendingchaos (Rhys Perry)

Differential Revision: https://reviews.llvm.org/D55223

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

[CMake] Add support for NO_INSTALL_RPATH argument in llvm_add_library()

Summary:
Allow clients to suppress setup of default RPATHs in designated library targets. This is used in LLDB when emitting liblldb as a framework bundle, which itself doesn't load further RPATH-dependent libraries.
This follows the approach in add_llvm_executable().

Reviewers: aprantl, JDevlieghere, davide, friss

Reviewed By: aprantl

Subscribers: mgorny, lldb-commits, llvm-commits, #lldb

Differential Revision: https://reviews.llvm.org/D55316

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

[IR] Don't assume all functions are 4 byte aligned

In some cases different alignments for function might be used to save
space e.g. thumb mode with -Oz will try to use 2 byte function
alignment. Similar patch that fixed this in other areas exists here
https://reviews.llvm.org/D46110

This was approved previously https://reviews.llvm.org/D55115 (r348215)
but when committed it caused failures on the sanitizer buildbots when
building llvm with clang (containing this patch). This is now fixed
because I've added a check to see if getting the parent module returns
null if it does then set the alignment to 0.

Differential Revision: https://reviews.llvm.org/D55115

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

[PM] Port LoadStoreVectorizer to the new pass manager.

Differential Revision: https://reviews.llvm.org/D54848

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

[LoopSimplifyCFG] Do not deal with loops with irreducible CFG inside

The current algorithm that collects live/dead/inloop blocks relies on some invariants
related to RPO and PO traversals. In particular, the important fact it requires is that
the only loop's latch is the first block in PO traversal. It also relies on fact that during
RPO we visit all prececessors of a block before we visit this block (backedges ignored).

If a loop has irreducible non-loop cycle inside, both these assumptions may break.
This patch adds detection for this situation and prohibits the terminator folding
for loops with irreducible CFG.

We can in theory support this later, for this some algorithmic changes are needed.
Besides, irreducible CFG is not a frequent situation and we can just don't bother.

Thanks @uabelho for finding this!

Differential Revision: https://reviews.llvm.org/D55357
Reviewed By: skatkov

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

[PowerPC] Fix assert from machine verify pass that missing undef register flag

Fix assert about using an undefined physical register in machine instruction verify pass.
The reason is that register flag undef is missing when doing transformation from If Conversion Pass.

```
Bad machine code: Using an undefined physical register
- function:    func_65
- basic block: %bb.0 entry (0x10024740738)
- instruction: BCLR killed $cr5lt, implicit $lr8, implicit $rm, implicit undef $x3
- operand 0:   killed $cr5lt
LLVM ERROR: Found 1 machine code errors.
```

There are also other existing testcases with same issue. So I add -verify-machineinstrs option to open verifying.

Differential Revision: https://reviews.llvm.org/D55408

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

[llvm-mca] Improve test (NFC)

Add more instructions to the test for Cortex.

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

[llvm-mca] Improve test (NFC)

Add a label to make explicit that the branch is short for Exynos.

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

[CodeExtractor] Store outputs at the first valid insertion point

When CodeExtractor outlines values which are used by the original
function, it must store those values in some in-out parameter. This
store instruction must not be inserted in between a PHI and an EH pad
instruction, as that results in invalid IR.

This fixes the following verifier failure seen while outlining within
ObjC methods with live exit values:

  The unwind destination does not have an exception handling instruction!
    %call35 = invoke i8* bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to i8* (i8*, i8*)*)(i8* %exn.adjusted, i8* %1)
            to label %invoke.cont34 unwind label %lpad33, !dbg !4183
  The unwind destination does not have an exception handling instruction!
    invoke void @objc_exception_throw(i8* %call35) #12
            to label %invoke.cont36 unwind label %lpad33, !dbg !4184
  LandingPadInst not the first non-PHI instruction in the block.
    %3 = landingpad { i8*, i32 }
            catch i8* null, !dbg !1411

rdar://46540815

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

Revert "[llvm-tapi] Don't override SequenceTraits for std::string"

Revert r348551 since it triggered some warnings that don't appear to have a quick fix.

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

Revert "[DemandedBits][BDCE] Support vectors of integers"

This reverts commit r348549. Causing assertion failures during
clang build.

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

[DAGCombiner] use root SDLoc for all nodes created by logic fold

If this is not a valid way to assign an SDLoc, then we get this
wrong all over SDAG.

I don't know enough about the SDAG to explain this. IIUC, theoretically,
debug info is not supposed to affect codegen. But here it has clearly
affected 3 different targets, and the x86 change is an actual improvement.

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

[llvm-tapi] Don't override SequenceTraits for std::string

Change the ELF YAML implementation of TextAPI so NeededLibs uses flow
sequence vector correctly instead of overriding the YAML implementation
for std::vector<std::string>>.

This should fix the test failure with the LLVM_LINK_LLVM_DYLIB build mentioned in D55381.

Still passes existing tests that cover this.

Differential Revision: https://reviews.llvm.org/D55390

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

[DAGCombiner] don't bother saving a SDLoc for a node that's dead; NFCI

We shouldn't care about the debug location for a node that
we're creating, but attaching the root of the pattern should
be the best effort. (If this is not true, then we are doing
it wrong all over the SDAG).

This is no-functional-change-intended, and there are no
regression test diffs...and that's what I expected. But
there's a similar line above this diff, where those
assumptions apparently do not hold.

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

[DemandedBits][BDCE] Support vectors of integers

DemandedBits and BDCE currently only support scalar integers. This
patch extends them to also handle vector integer operations. In this
case bits are not tracked for individual vector elements, instead a
bit is demanded if it is demanded for any of the elements. This matches
the behavior of computeKnownBits in ValueTracking and
SimplifyDemandedBits in InstCombine.

The getDemandedBits() method can now only be called on instructions that
have integer or vector of integer type. Previously it could be called on
any sized instruction (even if it was not particularly useful). The size
of the return value is now always the scalar size in bits (while
previously it was the type size in bits).

Differential Revision: https://reviews.llvm.org/D55297

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

[BDCE] Add tests for BDCE applied to vector instructions; NFC

These are baseline tests for D55297.

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

[DAGCombiner] more clean up in hoistLogicOpWithSameOpcodeHands(); NFC

This code can still misbehave.

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

Run `git ls-files '*.gn' '*.gni' | xargs -n 1 gn format`.

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

[gn build] merge r348505.

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

[X86] Directly create ADC/SBB nodes instead of using ADD/SUB with (and SETCC_CARRY, 1)

This addresses a FIXME and avoids depending on an isel pattern match I think. I've remove the isel patterns too since he have no lit tests left that cover them. Hopefully that really means they are unused.

I'm trying to decide if we need SETCC_CARRY. This removes one of its usages.

Differential Revision: https://reviews.llvm.org/D55355

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

[DAGCombiner] don't group bswap with casts in logic hoisting fold

This was probably organized as it was because bswap is a unary op.
But that's where the similarity to the other opcodes ends. We should
not limit this transform to scalars, and we should not try it if
either input has other uses. This is another step towards trying to
clean this whole function up to prevent it from causing infinite loops
and memory explosions.

Earlier commits in this series:
rL348501
rL348508
rL348518

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

[x86] add test for vector bitwise-logic-of-bswaps; NFC

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

[DAGCombiner] reduce indent; NFC

Unlike some of the folds in hoistLogicOpWithSameOpcodeHands()
above this shuffle transform, this has the expected hasOneUse()
checks in place.

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

[DagCombiner][X86] Simplify a ConcatVectors of a scalar_to_vector with undef.

This patch introduces a new DAGCombiner rule to simplify concat_vectors nodes:

concat_vectors( bitcast (scalar_to_vector %A), UNDEF)
    --> bitcast (scalar_to_vector %A)

This patch only partially addresses PR39257. In particular, it is enough to fix
one of the two problematic cases mentioned in PR39257. However, it is not enough
to fix the original test case posted by Craig; that particular case would
probably require a more complicated approach (and knowledge about used bits).

Before this patch, we used to generate the following code for function PR39257
(-mtriple=x86_64 , -mattr=+avx):

vmovsd  (%rdi), %xmm0           # xmm0 = mem[0],zero
vxorps  %xmm1, %xmm1, %xmm1
vblendps        $3, %xmm0, %xmm1, %xmm0 # xmm0 = xmm0[0,1],xmm1[2,3]
vmovaps %ymm0, (%rsi)
vzeroupper
retq

Now we generate this:

vmovsd  (%rdi), %xmm0           # xmm0 = mem[0],zero
vmovaps %ymm0, (%rsi)
vzeroupper
retq

As a side note: that VZEROUPPER is completely redundant...

I guess the vzeroupper insertion pass doesn't realize that the definition of
%xmm0 from vmovsd is already zeroing the upper half of %ymm0. Note that on
%-mcpu=btver2, we don't get that vzeroupper because pass vzeroupper insertion
%pass is disabled.

Differential Revision: https://reviews.llvm.org/D55274

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

[DAGCombiner] don't hoist logic op if operands have other uses, part 2

The PPC test with 2 extra uses seems clearly better by avoiding this transform.
With 1 extra use, we also prevent an extra register move (although that might
be an RA problem). The general rule should be to only make a change here if
it is always profitable. The x86 diffs are all neutral.

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

Fix Wdocumentation warning. NFCI.

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

[PowerPC] add tests for hoisting bitwise logic; NFC

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

Reapply "Adapt gcov to changes in CFE."

This reverts commit r348203 and reapplies D55085 with an additional
GCOV bugfix to make the change NFC for relative file paths in .gcno files.

Thanks to Ilya Biryukov for additional testing!

Original commit message:

    Update Diagnostic handling for changes in CFE.

    The clang frontend no longer emits the current working directory for
    DIFiles containing an absolute path in the filename: and will move the
    common prefix between current working directory and the file into the
    directory: component.

    https://reviews.llvm.org/D55085

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

[AArch64] Fix Exynos predicate

Fix predicate for arithmetic instructions with shift and/or extend.

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

[DAGCombiner] don't hoist logic op if operands have other uses

The AVX512 diffs are neutral, but the bswap test shows a clear overreach in
hoistLogicOpWithSameOpcodeHands(). If we don't check for other uses, we can
increase the instruction count.

This could also fight with transforms trying to go in the opposite direction
and possibly blow up/infinite loop. This might be enough to solve the bug
noted here:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608593.html

I did not add the hasOneUse() checks to all opcodes because I see a perf
regression for at least one opcode. We may decide that's irrelevant in the
face of potential compiler crashing, but I'll see if I can salvage that first.

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

[x86] add test for hoistLogicOpWithSameOpcodeHands with extra uses; NFC

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

[PDB] Move some code around.  NFC.

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

[gn build] Process .def.in files in llvm/Config and add lib/Target/BUILD.gn

Tweak write_cmake_config.py to also handle variable references looking @FOO@
(matching CMake's configure_file() function), and make it replace '\' 'n' in
values with a newline literal since there's no good portable way of passing a
real newline literal on a command line.

Use that to process all the .def.in files in llvm/include/Config and add
llvm/lib/Target/BUILD.gn, which (indirectly, through llvm-c/Target.h) includes
them.

Differential Revision: https://reviews.llvm.org/D55184

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

[DAGCombiner] refactor function that hoists bitwise logic; NFCI

Added FIXME and TODO comments for lack of safety checks.
This function is a suspect in out-of-memory errors as discussed in
the follow-up thread to r347917:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608593.html

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

Support skewed stream arrays.

VarStreamArray was built on the assumption that it is backed by a
StreamRef, and offset 0 of that StreamRef is the first byte of the first
record in the array.

This is a logical and intuitive assumption, but unfortunately we have
use cases where it doesn't hold. Specifically, a PDB module's symbol
stream is prefixed by 4 bytes containing a magic value, and the first
byte of record data in the array is actually at offset 4 of this byte
sequence.

Previously, we would just truncate the first 4 bytes and then construct
the VarStreamArray with the resulting StreamRef, so that offset 0 of the
underlying stream did correspond to the first byte of the first record,
but this is problematic, because symbol records reference other symbol
records by the absolute offset including that initial magic 4 bytes. So
if another record wants to refer to the first record in the array, it
would say "the record at offset 4".

This led to extremely confusing hacks and semantics in loading code, and
after spending 30 minutes trying to get some math right and failing, I
decided to fix this in the underlying implementation of VarStreamArray.
Now, we can say that a stream is skewed by a particular amount. This
way, when we access a record by absolute offset, we can use the same
values that the records themselves contain, instead of having to do
fixups.

Differential Revision: https://reviews.llvm.org/D55344

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

[X86] Refactored IsSplatVector to use switch. NFCI.

Initial step towards making the function more generic (and probably move into SelectionDAG).

This is necessary to avoid massive codegen bloat for PR38243 (Add modulo rotate support to LowerRotate).

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

[DEBUGINFO, NVPTX] Disable emission of ',debug' option if only debug directives are allowed.

Summary:
If the output of debug directives only is requested, we should drop
emission of ',debug' option from the target directive. Required for
supporting of nvprof profiler.

Reviewers: echristo

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D46061

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

[GVN] Don't perform scalar PRE on GEPs

Partial Redundancy Elimination of GEPs prevents CodeGenPrepare from
sinking the addressing mode computation of memory instructions back
to its uses. The problem comes from the insertion of PHIs, which
confuse CGP and make it bail.

I've autogenerated the check lines of an existing test and added a
store instruction to demonstrate the motivation behind this change.
The store is now using the gep instead of a phi.

Differential Revision: https://reviews.llvm.org/D55009

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

[DEBUGINFO, NVPTX]Emit last debugging directives.

Summary:
We may end up with not emitted debug directives at the end of the module
emission. Patch fixes this problem emitting those last directives the
end of the module emission.

Reviewers: echristo

Subscribers: jholewinski, llvm-commits

Differential Revision: https://reviews.llvm.org/D54320

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

DAGCombiner::visitINSERT_VECTOR_ELT - pull out repeated VT.getVectorNumElements(). NFCI.

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

[NFC][AArch64] Split out backend features

This patch splits backend features currently
hidden behind architecture versions.

For example, currently the only way to activate
complex numbers extension is targeting an v8.3
architecture, where after the patch this extension
can be added separately.

This refactoring is required by the new command lines proposal:
http://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html

Reviewers: DavidSpickett, olista01, t.p.northover

Subscribers: kristof.beyls, bryanpkc, javed.absar, pbarrio

Differential revision: https://reviews.llvm.org/D54633

--

It was reverted in rL348249 due a build bot failure in one of the
regression tests:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/14386

The problem seems to be that FileCheck behaves
different in windows and linux. This new patch
splits the test file in multiple,
and does more exact pattern matching attempting
to circumvent the issue.

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

[ARM][NFC] Adding another test for armcgp

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

AMDGPU: Generate VALU ThreeOp Integer instructions

Summary:
Original patch by: Fabian Wahlster <razor@singul4rity.com>

Change-Id: I148f692a88432541fad468963f58da9ddf79fac5

Reviewers: arsenm, rampitec

Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, b-sumner, llvm-commits

Differential Revision: https://reviews.llvm.org/D51995

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

[AMDGPU] Partial revert of rL348371: Turn on the DPP combiner by default

Turn the combiner back off as there're failures until the issue is fixed.

Differential revision: https://reviews.llvm.org/D55314

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

Fix -Wcovered-switch-default warning. NFCI.

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

Revert "[LoopSimplifyCFG] Delete dead in-loop blocks"

This reverts commit r348457.
The original commit causes clang to crash when doing an instrumented
build with a new pass manager. Reverting to unbreak our integrate.

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

Test commit: Removed trailing space in .txt file.

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

[ARM][NFC] Added extra arm-cgp test

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

[X86][NFC] Convert memcpy/memset tests to update_llc_test_checks.

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

[ARM GlobalISel] Nothing is legal for Thumb

...yet!

A lot of the current code should be shared for arm and thumb mode, but
until we add tests and work out some of the details (e.g. checking the
correct subtarget feature for G_SDIV) it's safer to bail out as early as
possible for thumb targets.

This should have arguably been part of r348347, which allowed Thumb
functions to be handled by the IR Translator.

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

[X86][NFC] Add more tests for memset.

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

[llvm-dwarfdump] - Simplify the test case.

The test was fully rewritten for simplification.

New test code was suggested by David Blaikie.

Differential revision: https://reviews.llvm.org/D55261

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

[InstCombine] foldICmpWithLowBitMaskedVal(): don't miscompile -1 vector elts

I was finally able to quantify what i thought was missing in the fix,
it was vector constants. If we have a scalar (and %x, -1),
it will be instsimplified before we reach this code,
but if it is a vector, we may still have a -1 element.

Thus, we want to avoid the fold if *at least one* element is -1.
Or in other words, ignoring the undef elements, no sign bits
should be set. Thus, m_NonNegative().

A follow-up for rL348181
https://bugs.llvm.org/show_bug.cgi?id=39861

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

[NFC][InstCombine] Add more miscompile tests for foldICmpWithLowBitMaskedVal()

We also have to me aware of vector constants. If at least one element
is -1, we can't transform.

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

[X86] Remove some leftover code for handling an i1 setcc type. NFC

We should only need to handle i8 now.

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

[LoopSimplifyCFG] Delete dead in-loop blocks

This patch teaches LoopSimplifyCFG to delete loop blocks that have
become unreachable after terminator folding has been done.

Differential Revision: https://reviews.llvm.org/D54023
Reviewed By: anna

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

InstCombine: Add some missing tests for scalarization

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

[llvm-objcopy] Change --only-keep to --only-section

I just hard core goofed when I wrote this and created a different name
for no good reason. I'm failry aware of most "fresh" users of llvm-objcopy
(that is, users which are not using it as a drop in replacement for GNU
objcopy) and can say that only "-j" is being used by such people so this
patch should strictly increase compatibility and not remove it.

Differential Revision: https://reviews.llvm.org/D52180

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

AArch64: Fix invalid CCMP emission

The code emitting AND-subtrees used to check whether any of the operands
was an OR in order to figure out if the result needs to be negated.
However the OR could be hidden in further subtrees and not immediately
visible.

Change the code so that canEmitConjunction() determines whether the
result of the generated subtree needs to be negated. Cleanup emission
logic to use this. I also changed the code a bit to make all negation
decisions early before we actually emit the subtrees.

This fixes http://llvm.org/PR39550

Differential Revision: https://reviews.llvm.org/D54137

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

Add objc.* ARC intrinsics and codegen them to their runtime methods.

Reviewers: erik.pilkington, ahatanak

Differential Revision: https://reviews.llvm.org/D55233

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

[MachineOutliner][NFC] Move yet another std::vector out of a loop

Once again, following the wisdom of the LLVM Programmer's Manual.

I think that's enough refactoring for today. :)

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

[MachineOutliner][NFC] Move std::vector out of loop

See http://llvm.org/docs/ProgrammersManual.html#vector

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

[MachineOutliner][NFC] Remove IntegerInstructionMap from InstructionMapper

Refactoring.

This map was only used when we used a string of integers to output the outlined
sequence. Since it's no longer used for anything, there's no reason to keep it
around.

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

[GlobalISel] Introduce G_BUILD_VECTOR, G_BUILD_VECTOR_TRUNC and G_CONCAT_VECTOR opcodes.

These opcodes are intended to subsume some of the capability of G_MERGE_VALUES,
as it was too powerful and thus complex to add deal with throughout the GISel
pipeline.

G_BUILD_VECTOR creates a vector value from a sequence of uniformly typed
scalar values. G_BUILD_VECTOR_TRUNC is a special opcode for handling scalar
operands which are larger than the destination vector element type, and
therefore does an implicit truncate.

G_CONCAT_VECTOR creates a vector by concatenating smaller, uniformly typed,
vectors together.

These will be used in a subsequent commit. This commit just adds the initial
infrastructure.

Differential Revision: https://reviews.llvm.org/D53594

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

[MachineOutliner][NFC] Remove buildCandidateList and replace with findCandidates

More refactoring.

Since the pruning logic has changed, and the candidate list is gone,
everything can be sunk into findCandidates.

We no longer need to keep track of the length of the longest substring, so we
can drop all of that logic as well.

After this, we just find all of the candidates and move to outlining.

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

[MachineOutliner][NFC] Candidates don't need to be shared_ptrs anymore

More refactoring.

After the changes to the pruning logic, and removing CandidateList, there's
no reason for Candiates to be shared_ptrs (or pointers at all).

std::shared_ptr<Candidate> -> Candidate.

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

Revert r347934 "[SCEV] Guard movement of insertion point for loop-invariants"

This change caused SEGVs in instcombine. (The r347934 change seems to me to be a
precipitating cause, not a root cause. Details are on the llvm-commits thread
for r347934.)

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

[WebAssembly] Change event section code to 13

Summary:
We decided to change the event section code from 12 to 13 as new
`DataCount` section in the bulk memory operations proposal will take the
code 12 instead.

Reviewers: sbc100

Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits

Differential Revision: https://reviews.llvm.org/D55343

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

[InstCombine] remove dead code from visitExtractElement

Extracting from a splat constant is always handled by InstSimplify.
Move the test for this from InstCombine to InstSimplify to make
sure that stays true.

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