[PowerPC]Exploit P9 vabsdu for unsigned vselect patterns

For type v4i32/v8ii16/v16i8, do following transforms:
  (vselect (setcc a, b, setugt), (sub a, b), (sub b, a)) -> (vabsd a, b)
  (vselect (setcc a, b, setuge), (sub a, b), (sub b, a)) -> (vabsd a, b)
  (vselect (setcc a, b, setult), (sub b, a), (sub a, b)) -> (vabsd a, b)
  (vselect (setcc a, b, setule), (sub b, a), (sub a, b)) -> (vabsd a, b)

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

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

[gn build] Add build file for llvm-objcopy

Needed by check-lld.

This should've been part of r349486 but I messed up.

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

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

Re-land "Fix MSVC dependency issue between Clang-tablegen and LLVM-tablegen"

Previously, when compiling Visual Studio targets, one could see random build errors. This was caused by tablegen projects using the same build folders.
This workaround simply chains tablegen projects.

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

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

Add llvm-objdump man page

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

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

[AArch64] Simplify the Exynos M3 pipeline model

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

[AArch64] Fix instructions order (NFC)

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

[llvm-mca] Improve test (NFC)

Add more instruction variations for Exynos.

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

[DebugInfo] Move several private headers to include directory

This patch moved the following files in lib/CodeGen/AsmPrinter/
  AsmPrinterHandler.h
  DbgEntityHistoryCalculator.h
  DebugHandlerBase.h
to include/llvm/CodeGen directory.

Such a change will enable Target to extend DebugHandlerBase
and emit Target specific debug info sections.

Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D55755

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

[InstCombine] add tests for extract of vector load; NFC

There's a mismatch internally about how we are handling these patterns.
We count loads as cheapToScalarize(), but then we don't actually
scalarize them, so that can leave extra instructions compared to where
we started when scalarizing other ops. If it's cheapToScalarize, then
we should be scalarizing.

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

Preserve the linkage for objc* intrinsics as clang will set them to weak_external in some cases

Clang uses weak linkage for objc runtime functions when they are not available on the platform.

The intrinsic has this linkage so we just need to pass that on to the runtime call.

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

Add nonlazybind to objc_retain/objc_release when converting from intrinsics.

For performance reasons, clang set nonlazybind on these functions.  Now that we
are using intrinsics instead of runtime calls, we should set this attribute when
creating the runtime functions.

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

[LAA] Introduce enum for vectorization safety status (NFC).

This patch adds a VectorizationSafetyStatus enum, which will be extended
in a follow up patch to distinguish between 'safe with runtime checks'
and 'known unsafe' dependences.

Reviewers: anemet, anna, Ayal, hsaito

Reviewed By: Ayal

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

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

[asan] Restore ODR-violation detection on vtables

Summary:
unnamed_addr is still useful for detecting of ODR violations on vtables

Still unnamed_addr with lld and --icf=safe or --icf=all can trigger false
reports which can be avoided with --icf=none or by using private aliases
with -fsanitize-address-use-odr-indicator

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: kubamracek, hiraditya, llvm-commits

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

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

[LoopVectorize] auto-generate complete checks; NFC

The first test claims to show that the vectorizer will
generate a vector load/loop, but then this file runs
other passes which might scalarize that op. I'm removing
instcombine from the RUN line here to break that dependency.
Also, I'm generating full checks to make it clear exactly
what the vectorizer has done.

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

Rewrite objc intrinsics to runtime methods in PreISelIntrinsicLowering instead of SDAG.

SelectionDAG currently changes these intrinsics to function calls, but that won't work
for other ISel's.  Also we want to eventually support nonlazybind and weak linkage coming
from the front-end which we can't do in SelectionDAG.

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

[AArch64] Avoid crashing on .seh directives in assembly

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

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

[InstCombine] auto-generate complete checks; NFC

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

Revert r349541 (Fix MSVC dependency issue between Clang-tablegen and LLVM-tablegen)

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

[asan] In llvm.asan.globals, allow entries to be non-GlobalVariable and skip over them

Looks like there are valid reasons why we need to allow bitcasts in llvm.asan.globals, see discussion at https://github.com/apple/swift-llvm/pull/133. Let's look through bitcasts when iterating over entries in the llvm.asan.globals list.

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

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

[AARCH64] Added test case for PR40091

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

Fix MSVC dependency issue between Clang-tablegen and LLVM-tablegen

Previously, when compiling Visual Studio targets, one could see random build errors. This was caused by tablegen projects using the same build folders.
This workaround simply chains tablegen projects.

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

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

[llvm-mca] Update the Exynos test cases (NFC)

Add more entropy to the test cases.

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

[llvm-mca] Dump mask in hex

Dump the resources masks as hexadecimal.

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

Change the objc ARC optimizer to use the new objc.* intrinsics

We're moving ARC optimisation and ARC emission in clang away from runtime methods
and towards intrinsics.  This is the part which actually uses the intrinsics in the ARC
optimizer when both analyzing the existing calls and emitting new ones.

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

Reviewers: ahatanak

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

[X86] Add BSR to isUseDefConvertible.

We already had BSF here as part of __builtin_ffs improvements and I was just wondering yesterday whether we should have BSR there.

This addresses one issue from PR40090.

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

[InstCombine] Simplify cttz/ctlz + icmp eq/ne into mask check

Checking whether a number has a certain number of trailing / leading
zeros means checking whether it is of the form XXXX1000 / 0001XXXX,
which can be done with an and+icmp.

Related to https://bugs.llvm.org/show_bug.cgi?id=28668. As a next
step, this can be extended to non-equality predicates.

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

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

[AMDGPU] Removed the unnecessary operand size-check-assert from processBaseWithConstOffset().

Summary: 32bit operand sizes are guaranteed by the opcode check AMDGPU::V_ADD_I32_e64 and
         AMDGPU::V_ADDC_U32_e64. Therefore, we don't any additional operand size-check-assert.

Author: FarhanaAleen

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

DebugInfo: Fix missing local imported entities after r349207

Post commit review/bug reported by Pavel Labath - thanks!

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

[SCCP] Get rid of redundant call for getPredicateInfoFor (NFC).

We can use the result fetched a few lines above.

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

[X86] Don't use SplitOpsAndApply to create ISD::UADDSAT/ISD::USUBSAT nodes. Let type legalization and op legalization deal with it.

Now that we've switched to target independent nodes we can rely on generic infrastructure to do the legalization for us.

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

[InstCombine] refactor isCheapToScalarize(); NFC

As the FIXME indicates, this has the potential to go
overboard. So I'm not sure if it's even worth keeping
this vs. iteratively doing simple matches, but we might
as well clean it up.

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

[X86] Use SADDSAT/SSUBSAT instead of ADDS/SUBS

Migrate the X86 backend from X86ISD opcodes ADDS and SUBS to generic
ISD opcodes SADDSAT and SSUBSAT. This also improves scodegen for
@llvm.sadd.sat() and @llvm.ssub.sat() intrinsics.

This is a followup to D55787 and part of PR40056.

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

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

[X86] Create PSUBUS from (add (umax X, C), -C)

InstCombine seems to canonicalize or PSUB patter into a max with the cosntant and an add with an inverse of the constant.

This patch recognizes this pattern and turns it into PSUBUS. Future work could improve undef element handling.

Fixes some of PR40053

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

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

Buildfix for r345516 (Clang compilation failing).

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

[CMake] Default options for faster executables on MSVC

- Disable incremental linking by default. /INCREMENTAL adds extra thunks in the EXE, which makes execution slower.
- Set /MT (static CRT lib) by default instead of CMake's default /MD (dll CRT lib). The previous default /MD makes all DLL functions to be thunked, thus making execution slower (memcmp, memset, etc.)
- Adds LLVM_ENABLE_INCREMENTAL_LINK which is set to OFF by default.

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

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

[llvm-symbolizer] Omit stderr output when symbolizing a crash

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

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

[InstCombine] add tests for scalarization; NFC

We miss pattern matching a splat constant if it has undef elements.

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

Add FMF management to common fp intrinsics in GlobalIsel

Summary: This the initial code change to facilitate managing FMF flags from Instructions to MI wrt Intrinsics in Global Isel.  Eventually the GlobalObserver interface will be added as well, where FMF additions can be tracked for the builder and CSE.

Reviewers: aditya_nandakumar, bogner

Reviewed By: bogner

Subscribers: rovka, kristof.beyls, javed.absar

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

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

[LoopVectorize] Rename pass options. NFC.

Rename:
NoUnrolling to InterleaveOnlyWhenForced
and
AlwaysVectorize to !VectorizeOnlyWhenForced

Contrary to what the name 'AlwaysVectorize' suggests, it does not
unconditionally vectorize all loops, but applies a cost model to
determine whether vectorization is profitable to all loops. Hence,
passing false will disable the cost model, except when a loop is marked
with llvm.loop.vectorize.enable. The 'OnlyWhenForced' suffix (suggested
by @hfinkel in D55716) better matches this behavior.

Similarly, 'NoUnrolling' disables the profitability cost model for
interleaving (a term to distinguish it from unrolling by the
LoopUnrollPass); rename it for consistency.

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

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

[X86][SSE] Don't use 'sign bit select' vXi8 ROTL lowering for constant rotation amounts

Noticed by @spatel on D55747 - we get much better codegen if we use the regular shift expansion.

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

[LoopUnroll] Honor '#pragma unroll' even with -fno-unroll-loops.

When using clang with `-fno-unroll-loops` (implicitly added with `-O1`),
the LoopUnrollPass is not not added to the (legacy) pass pipeline. This
also means that it will not process any loop metadata such as
llvm.loop.unroll.enable (which is generated by #pragma unroll or
WarnMissedTransformationsPass emits a warning that a forced
transformation has not been applied (see
https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181210/610833.html).
Such explicit transformations should take precedence over disabling
heuristics.

This patch unconditionally adds LoopUnrollPass to the optimizing
pipeline (that is, it is still not added with `-O0`), but passes a flag
indicating whether automatic unrolling is dis-/enabled. This is the same
approach as LoopVectorize uses.

The new pass manager's pipeline builder has no option to disable
unrolling, hence the problem does not apply.

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

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

[X86][SSE] Don't use 'sign bit select' vXi8 ROTL lowering for splat rotation amounts

Noticed by @spatel on D55747 - we get much better codegen if we use the regular shift expansion.

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

[MIPS GlobalISel] Select G_SDIV, G_UDIV, G_SREM and G_UREM

Add support for s64 libcalls for G_SDIV, G_UDIV, G_SREM and G_UREM
and use integer type of correct size when creating arguments for
CLI.lowerCall.
Select G_SDIV, G_UDIV, G_SREM and G_UREM for types s8, s16, s32 and s64
on MIPS32.

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

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

[gn build] Add build file for llvm-pdbutil

Needed for check-lld.

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

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

[gn build] Add build file for llvm-bcanalyzer

Needed for check-lld.

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

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

[gn build] Add build files for llvm-ar, llvm-nm, llvm-objdump, llvm-readelf

Also add build files for deps DebugInfo/Symbolize, ToolDrivers/dll-tool.
Also add gn/build/libs/xar (needed by llvm-objdump).

Also delete an incorrect part of the symlink description in //BUILD.gn (it used
to be true before I made the symlink step write a stamp file; now it's no
longer true).

These are all binaries needed by check-lld that need symlinks.

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

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

[X86][SSE] Add shift combine 'out of range' tests with UNDEFs

Shows failure to simplify out of range shift amounts to UNDEF if any element is UNDEF.

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

[X86] Use UADDSAT/USUBSAT instead of ADDUS/SUBUS

Replace the X86ISD opcodes ADDUS and SUBUS with generic ISD opcodes
UADDSAT and USUBSAT. As a side-effect, this also makes codegen for
the @llvm.uadd.sat and @llvm.usub.sat intrinsics reasonable.

This only replaces use in the X86 backend, and does not move any of
the ADDUS/SUBUS X86 specific combines into generic codegen.

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

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

[SelectionDAG][X86] Fix [US](ADD|SUB)SAT vector legalization, add tests

Integer result promotion needs to use the scalar size, and we need
support for result widening.

This is in preparation for D55787.

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

[docs] Improve HowToCrossCompilerBuiltinsOnArm

Some recent experience on llvm-dev pointed out some errors in the document:
- Assumption of ninja
- Use of --march rather than -march
- Problems with host include files when a multiarch setup was used
- Insufficient target information passed to assembler
- Instructions on using the cmake cache file BaremetalARM.cmake were
  incomplete

There was also insufficient guidance on what to do when various stages
failed due to misconfiguration or missing steps.

Summary of changes:
- Fixed problems above
- Added a troubleshooting section with common errors.
- Cleared up one "at time of writing" that is no longer a problem.

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

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

[llvm-dwarfdump] - Do not error out on R_X86_64_DTPOFF64/R_X86_64_DTPOFF32 relocations.

This is https://bugs.llvm.org/show_bug.cgi?id=39992,

If we have the following code (test.cpp):

thread_local int tdata = 24;
and build an .o file with debug information:

clang --target=x86_64-pc-linux -c bar.cpp -g

Then object produced may have R_X86_64_DTPOFF64/R_X86_64_DTPOFF32 relocations.
(clang emits R_X86_64_DTPOFF64 and gcc emits R_X86_64_DTPOFF32 for the code above for me)

Currently, llvm-dwarfdump fails to compute this TLS relocation when dumping
object and reports an
error:
failed to compute relocation: R_X86_64_DTPOFF64, Invalid data was encountered while parsing the file

This relocation represents the offset in the TLS block and resolved by the linker,
but this info is unavailable at the
point when the object file is dumped by this tool.

The patch adds the simple evaluation for such relocations to avoid emitting errors.
Resulting behavior seems to be equal to GNU dwarfdump.

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

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

[MIPS GlobalISel] ClampScalar G_AND G_OR and G_XOR

Add narrowScalar for G_AND and G_XOR.
Legalize G_AND G_OR and G_XOR for types other then s32
with clampScalar on MIPS32.

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

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

[AArch64] - Return address signing dwarf support

- Reapply changes intially introduced in r343089
- The archtecture info is no longer loaded whenever a DWARFContext is created
- The runtimes libraries (santiziers) make use of the dwarf context classes but
  do not intialise the target info
- The architecture of the object can be obtained without loading the target info
- Adding a method to the dwarf context to get this information and multiplex the
  string printing later on

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

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

[X86][AVX] Add 256/512-bit vector funnel shift tests

Extra coverage for D55747

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

[X86][SSE] Add 128-bit vector funnel shift tests

Extra coverage for D55747

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

[IPO][AVR] Create new Functions in the default address space specified in the data layout

This modifies the IPO pass so that it respects any explicit function
address space specified in the data layout.

In targets with nonzero program address spaces, all functions should, by
default, be placed into the default program address space.

This is required for Harvard architectures like AVR. Without this, the
functions will be marked as residing in data space, and thus not be
callable.

This has no effect to any in-tree official backends, as none use an
explicit program address space in their data layouts.

Patch by Tim Neumann.

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

AMDGPU: Legalize/regbankselect frame_index

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

AMDGPU: Legalize/regbankselect fma

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

[TargetLowering] Fallback from SimplifyDemandedVectorElts to SimplifyDemandedBits

For opcodes not covered by SimplifyDemandedVectorElts, SimplifyDemandedBits might be able to help now that it supports demanded elts as well.

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

SROA: preserve alignment tags on loads and stores.

When splitting up an alloca's uses we were dropping any explicit
alignment tags, which means they default to the ABI-required default
alignment and this can cause miscompiles if the real value was smaller.

Also refactor the TBAA metadata into a parent class since it's shared by
both children anyway.

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

GlobalISel: Improve crash on invalid mapping

If NumBreakDowns is 0, BreakDown is null.
This trades a null dereference with an assert somewhere
else.

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

AMDGPU/GlobalISel: Legalize/regbankselect fneg/fabs/fsub

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

[X86][SSE] Move VSRAI sign extend in reg fold into SimplifyDemandedBits

(VSRAI (VSHLI X, C1), C1) --> X iff NumSignBits(X) > C1

This works better as part of SimplifyDemandedBits than part of the general combine.

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

[X86][SSE] Replace (VSRLI (VSRAI X, Y), 31) -> (VSRLI X, 31) fold.

This fold was incredibly specific - replace with a SimplifyDemandedBits fold to remove a VSRAI if only the original sign bit is demanded (its guaranteed to stay the same).

Test change is merely a rescheduling.

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

Introduce control flow speculation tracking pass for AArch64

The pass implements tracking of control flow miss-speculation into a "taint"
register. That taint register can then be used to mask off registers with
sensitive data when executing under miss-speculation, a.k.a. "transient
execution".
This pass is aimed at mitigating against SpectreV1-style vulnarabilities.

At the moment, it implements the tracking of miss-speculation of control
flow into a taint register, but doesn't implement a mechanism yet to then
use that taint register to mask off vulnerable data in registers (something
for a follow-on improvement). Possible strategies to mask out vulnerable
data that can be implemented on top of this are:
- speculative load hardening to automatically mask of data loaded
  in registers.
- using intrinsics to mask of data in registers as indicated by the
  programmer (see https://lwn.net/Articles/759423/).

For AArch64, the following implementation choices are made.
Some of these are different than the implementation choices made in
the similar pass implemented in X86SpeculativeLoadHardening.cpp, as
the instruction set characteristics result in different trade-offs.
- The speculation hardening is done after register allocation. With a
  relative abundance of registers, one register is reserved (X16) to be
  the taint register. X16 is expected to not clash with other register
  reservation mechanisms with very high probability because:
  . The AArch64 ABI doesn't guarantee X16 to be retained across any call.
  . The only way to request X16 to be used as a programmer is through
    inline assembly. In the rare case a function explicitly demands to
    use X16/W16, this pass falls back to hardening against speculation
    by inserting a DSB SYS/ISB barrier pair which will prevent control
    flow speculation.
- It is easy to insert mask operations at this late stage as we have
  mask operations available that don't set flags.
- The taint variable contains all-ones when no miss-speculation is detected,
  and contains all-zeros when miss-speculation is detected. Therefore, when
  masking, an AND instruction (which only changes the register to be masked,
  no other side effects) can easily be inserted anywhere that's needed.
- The tracking of miss-speculation is done by using a data-flow conditional
  select instruction (CSEL) to evaluate the flags that were also used to
  make conditional branch direction decisions. Speculation of the CSEL
  instruction can be limited with a CSDB instruction - so the combination of
  CSEL + a later CSDB gives the guarantee that the flags as used in the CSEL
  aren't speculated. When conditional branch direction gets miss-speculated,
  the semantics of the inserted CSEL instruction is such that the taint
  register will contain all zero bits.
  One key requirement for this to work is that the conditional branch is
  followed by an execution of the CSEL instruction, where the CSEL
  instruction needs to use the same flags status as the conditional branch.
  This means that the conditional branches must not be implemented as one
  of the AArch64 conditional branches that do not use the flags as input
  (CB(N)Z and TB(N)Z). This is implemented by ensuring in the instruction
  selectors to not produce these instructions when speculation hardening
  is enabled. This pass will assert if it does encounter such an instruction.
- On function call boundaries, the miss-speculation state is transferred from
  the taint register X16 to be encoded in the SP register as value 0.

Future extensions/improvements could be:
- Implement this functionality using full speculation barriers, akin to the
  x86-slh-lfence option. This may be more useful for the intrinsics-based
  approach than for the SLH approach to masking.
  Note that this pass already inserts the full speculation barriers if the
  function for some niche reason makes use of X16/W16.
- no indirect branch misprediction gets protected/instrumented; but this
  could be done for some indirect branches, such as switch jump tables.

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

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

[AArch64] [MinGW] Allow enabling SEH exceptions

The default still is dwarf, but SEH exceptions can now be enabled
optionally for the MinGW target.

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

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

[X86] Add test cases to show isel failing to match BMI blsmsk/blsi/blsr when the flag result is used.

A similar things happen to TBM instructions which we already have tests for.

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

[PowerPC][NFC]Update vabsd cases with vselect test cases

Power9 VABSDU* instructions can be exploited for some special vselect sequences.
Check in the orignal test case here, later the exploitation patch will update this
and reviewers can check the differences easily.

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

[PowerPC] Exploit power9 new instruction setb

Check the expected pattens feeding to SELECT_CC like:
   (select_cc lhs, rhs,  1, (sext (setcc [lr]hs, [lr]hs, cc2)), cc1)
   (select_cc lhs, rhs, -1, (zext (setcc [lr]hs, [lr]hs, cc2)), cc1)
   (select_cc lhs, rhs,  0, (select_cc [lr]hs, [lr]hs,  1, -1, cc2), seteq)
   (select_cc lhs, rhs,  0, (select_cc [lr]hs, [lr]hs, -1,  1, cc2), seteq)
Further transform the sequence to comparison + setb if hits.

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

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

[NFC] Add new test to cover the lhs scheduling issue for P9.

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

[X86] Add test case for PR40060. NFC

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

[X86] Const correct some helper functions X86InstrInfo.cpp. NFC

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

[NFC] fix test case issue that with wrong label check.

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

[CaptureTracking] Pass MaxUsesToExplore from wrappers to the actual implementation

This is a follow up for rL347910. In the original patch I somehow forgot to pass
the limit from wrappers to the function which actually does the job.

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

[PowerPC] Improve vec_abs on P9

Improve the current vec_abs support on P9, generate ISD::ABS node for vector types,
combine ABS node to VABSD node for some special cases to make use of P9 VABSD* insns,
do custom lowering to vsub(vneg later)+vmax if it has no combination opportunity.

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

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

[Support] Fix GNU/kFreeBSD build

Patch by James Clarke.

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

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

[codeview] Update comment on aligning symbol records

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

[FileCheck] Try to fix test on windows due to r349418

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

[codeview] Align symbol records to save 441MB during linking clang.pdb

In PDBs, symbol records must be aligned to four bytes. However, in the
object file, symbol records may not be aligned. MSVC does not pad out
symbol records to make sure they are aligned. That means the linker has
to do extra work to insert the padding. Currently, LLD calculates the
required space with alignment, and copies each record one at a time
while padding them out to the correct size. It has a fast path that
avoids this copy when the records are already aligned.

This change fixes a bug in that codepath so that the copy is actually
saved, and tweaks LLVM's symbol record emission to align symbol records.
Here's how things compare when doing a plain clang Release+PDB build:
- objs are 0.65% bigger (negligible)
- link is 3.3% faster (negligible)
- saves allocating 441MB
- new LLD high water mark is ~1.05GB

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

Recommit r348806: DebugInfo: Use symbol difference for CU length to simplify assembly reading/editing

Mucking about simplifying a test case ( https://reviews.llvm.org/D55261 ) I stumbled across something I've hit before - that LLVM's (GCC's does too, FWIW) assembly output includes a hardcode length for a DWARF unit in its header. Instead we could emit a label difference - making the assembly easier to read/edit (though potentially at a slight (I haven't tried to observe it) performance cost of delaying/sinking the length computation into the MC layer).

Fix: Predicated all the changes (including creating the labels, even if they aren't used/needed) behind the NVPTX useSectionsAsReferences, avoiding emitting labels in NVPTX where ptxas can't parse them.

Reviewers: JDevlieghere, probinson, ABataev

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

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

[FileCheck] Annotate input dump (final tweaks)

Apply final suggestions from probinson for this patch series plus a
few more tweaks:

* Improve various docs, for MatchType in particular.

* Rename some members of MatchType.  The main problem was that the
  term "final match" became a misnomer when CHECK-COUNT-<N> was
  created.

* Split InputStartLine, etc. declarations into multiple lines.

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

Reviewed By: probinson

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

[FileCheck] Annotate input dump (7/7)

This patch implements annotations for diagnostics reporting CHECK-NOT
failed matches.  These diagnostics are enabled by -vv.  As for
diagnostics reporting failed matches for other directives, these
annotations mark the search ranges using `X~~`.  The difference here
is that failed matches for CHECK-NOT are successes not errors, so they
are green not red when colors are enabled.

For example:

```
$ FileCheck -dump-input=help
The following description was requested by -dump-input=help to
explain the input annotations printed by -dump-input=always and
-dump-input=fail:

  - L:     labels line number L of the input file
  - T:L    labels the only match result for a pattern of type T from line L of
           the check file
  - T:L'N  labels the Nth match result for a pattern of type T from line L of
           the check file
  - ^~~    marks good match (reported if -v)
  - !~~    marks bad match, such as:
           - CHECK-NEXT on same line as previous match (error)
           - CHECK-NOT found (error)
           - CHECK-DAG overlapping match (discarded, reported if -vv)
  - X~~    marks search range when no match is found, such as:
           - CHECK-NEXT not found (error)
           - CHECK-NOT not found (success, reported if -vv)
           - CHECK-DAG not found after discarded matches (error)
  - ?      marks fuzzy match when no match is found
  - colors success, error, fuzzy match, discarded match, unmatched input

If you are not seeing color above or in input dumps, try: -color

$ FileCheck -vv -dump-input=always check5 < input5 |& sed -n '/^<<<</,$p'
<<<<<<
         1: abcdef
check:1     ^~~
not:2          X~~
         2: ghijkl
not:2       ~~~
check:3        ^~~
         3: mnopqr
not:4       X~~~~~
         4: stuvwx
not:4       ~~~~~~
         5:
eof:4       ^
>>>>>>

$ cat check5
CHECK: abc
CHECK-NOT: foobar
CHECK: jkl
CHECK-NOT: foobar

$ cat input5
abcdef
ghijkl
mnopqr
stuvwx
```

Reviewed By: george.karpenkov, probinson

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

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

[FileCheck] Annotate input dump (6/7)

This patch implements input annotations for diagnostics reporting
CHECK-DAG discarded matches.  These diagnostics are enabled by -vv.
These annotations mark discarded match ranges using `!~~` because they
are bad matches even though they are not errors.

CHECK-DAG discarded matches create another case where there can be
multiple match results for the same directive.

For example:

```
$ FileCheck -dump-input=help
The following description was requested by -dump-input=help to
explain the input annotations printed by -dump-input=always and
-dump-input=fail:

  - L:     labels line number L of the input file
  - T:L    labels the only match result for a pattern of type T from line L of
           the check file
  - T:L'N  labels the Nth match result for a pattern of type T from line L of
           the check file
  - ^~~    marks good match (reported if -v)
  - !~~    marks bad match, such as:
           - CHECK-NEXT on same line as previous match (error)
           - CHECK-NOT found (error)
           - CHECK-DAG overlapping match (discarded, reported if -vv)
  - X~~    marks search range when no match is found, such as:
           - CHECK-NEXT not found (error)
           - CHECK-DAG not found after discarded matches (error)
  - ?      marks fuzzy match when no match is found
  - colors success, error, fuzzy match, discarded match, unmatched input

If you are not seeing color above or in input dumps, try: -color

$ FileCheck -vv -dump-input=always check4 < input4 |& sed -n '/^<<<</,$p'
<<<<<<
         1: abcdef
dag:1       ^~~~
dag:2'0       !~~~ discard: overlaps earlier match
         2: cdefgh
dag:2'1     ^~~~
check:3         X~ error: no match found
>>>>>>

$ cat check4
CHECK-DAG: abcd
CHECK-DAG: cdef
CHECK: efgh

$ cat input4
abcdef
cdefgh
```

This shows that the line 3 CHECK fails to match even though its
pattern appears in the input because its search range starts after the
line 2 CHECK-DAG's match range.  The trouble might be that the line 2
CHECK-DAG's match range is later than expected because its first match
range overlaps with the line 1 CHECK-DAG match range and thus is
discarded.

Because `!~~` for CHECK-DAG does not indicate an error, it is not
colored red.  Instead, when colors are enabled, it is colored cyan,
which suggests a match that went cold.

Reviewed By: george.karpenkov, probinson

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

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

[FileCheck] Annotate input dump (5/7)

This patch implements input annotations for diagnostics enabled by -v,
which report good matches for directives.  These annotations mark
match ranges using `^~~`.

For example:

```
$ FileCheck -dump-input=help
The following description was requested by -dump-input=help to
explain the input annotations printed by -dump-input=always and
-dump-input=fail:

  - L:     labels line number L of the input file
  - T:L    labels the only match result for a pattern of type T from line L of
           the check file
  - T:L'N  labels the Nth match result for a pattern of type T from line L of
           the check file
  - ^~~    marks good match (reported if -v)
  - !~~    marks bad match, such as:
           - CHECK-NEXT on same line as previous match (error)
           - CHECK-NOT found (error)
  - X~~    marks search range when no match is found, such as:
           - CHECK-NEXT not found (error)
  - ?      marks fuzzy match when no match is found
  - colors success, error, fuzzy match, unmatched input

If you are not seeing color above or in input dumps, try: -color

$ FileCheck -v -dump-input=always check3 < input3 |& sed -n '/^<<<</,$p'
<<<<<<
         1: abc foobar def
check:1     ^~~
not:2           !~~~~~     error: no match expected
check:3                ^~~
>>>>>>

$ cat check3
CHECK:     abc
CHECK-NOT: foobar
CHECK:     def

$ cat input3
abc foobar def
```

-vv enables these annotations for FileCheck's implicit EOF patterns as
well.  For an example where EOF patterns become relevant, see patch 7
in this series.

If colors are enabled, `^~~` is green to suggest success.

-v plus color enables highlighting of input text that has no final
match for any expected pattern.  The highlight uses a cyan background
to suggest a cold section.  This highlighting can make it easier to
spot text that was intended to be matched but that failed to be
matched in a long series of good matches.

CHECK-COUNT-<num> good matches are another case where there can be
multiple match results for the same directive.

Reviewed By: george.karpenkov, probinson

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

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

[FileCheck] Annotate input dump (4/7)

This patch implements input annotations for diagnostics that report
unexpected matches for CHECK-NOT.  Like wrong-line matches for
CHECK-NEXT, CHECK-SAME, and CHECK-EMPTY, these annotations mark match
ranges using red `!~~` to indicate bad matches that are errors.

For example:

```
$ FileCheck -dump-input=help
The following description was requested by -dump-input=help to
explain the input annotations printed by -dump-input=always and
-dump-input=fail:

  - L:     labels line number L of the input file
  - T:L    labels the only match result for a pattern of type T from line L of
           the check file
  - T:L'N  labels the Nth match result for a pattern of type T from line L of
           the check file
  - !~~    marks bad match, such as:
           - CHECK-NEXT on same line as previous match (error)
           - CHECK-NOT found (error)
  - X~~    marks search range when no match is found, such as:
           - CHECK-NEXT not found (error)
  - ?      marks fuzzy match when no match is found
  - colors error, fuzzy match

If you are not seeing color above or in input dumps, try: -color

$ FileCheck -v -dump-input=always check3 < input3 |& sed -n '/^<<<</,$p'
<<<<<<
       1: abc foobar def
not:2         !~~~~~     error: no match expected
>>>>>>

$ cat check3
CHECK:     abc
CHECK-NOT: foobar
CHECK:     def

$ cat input3
abc foobar def
```

Reviewed By: george.karpenkov, probinson

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

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

[FileCheck] Annotate input dump (3/7)

This patch implements input annotations for diagnostics that report
wrong-line matches for the directives CHECK-NEXT, CHECK-SAME, and
CHECK-EMPTY.  Instead of the usual `^~~`, which is used by later
patches for good matches, these annotations use `!~~` to mark the bad
match ranges so that this category of errors is visually distinct.
Because such matches are errors, these annotates are red when colors
are enabled.

For example:

```
$ FileCheck -dump-input=help
The following description was requested by -dump-input=help to
explain the input annotations printed by -dump-input=always and
-dump-input=fail:

  - L:     labels line number L of the input file
  - T:L    labels the only match result for a pattern of type T from line L of
           the check file
  - T:L'N  labels the Nth match result for a pattern of type T from line L of
           the check file
  - !~~    marks bad match, such as:
           - CHECK-NEXT on same line as previous match (error)
  - X~~    marks search range when no match is found, such as:
           - CHECK-NEXT not found (error)
  - ?      marks fuzzy match when no match is found
  - colors error, fuzzy match

If you are not seeing color above or in input dumps, try: -color

$ FileCheck -v -dump-input=always check2 < input2 |& sed -n '/^<<<</,$p'
<<<<<<
        1: foo bar
next:2         !~~ error: match on wrong line
>>>>>>

$ cat check2
CHECK: foo
CHECK-NEXT: bar

$ cat input2
foo bar
```

Reviewed By: george.karpenkov, probinson

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

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

[FileCheck] Annotate input dump (2/7)

This patch implements input annotations for diagnostics that suggest
fuzzy matches for directives for which no matches were found.  Instead
of using the usual `^~~`, which is used by later patches for good
matches, these annotations use `?` so that fuzzy matches are visually
distinct.  No tildes are included as these diagnostics (independently
of this patch) currently identify only the start of the match.

For example:

```
$ FileCheck -dump-input=help
The following description was requested by -dump-input=help to
explain the input annotations printed by -dump-input=always and
-dump-input=fail:

  - L:     labels line number L of the input file
  - T:L    labels the only match result for a pattern of type T from line L of
           the check file
  - T:L'N  labels the Nth match result for a pattern of type T from line L of
           the check file
  - X~~    marks search range when no match is found
  - ?      marks fuzzy match when no match is found
  - colors error, fuzzy match

If you are not seeing color above or in input dumps, try: -color

$ FileCheck -v -dump-input=always check1 < input1 |& sed -n '/^<<<</,$p'
<<<<<<
          1: ; abc def
          2: ; ghI jkl
next:3'0     X~~~~~~~~ error: no match found
next:3'1       ?       possible intended match
>>>>>>

$ cat check1
CHECK: abc
CHECK-SAME: def
CHECK-NEXT: ghi
CHECK-SAME: jkl

$ cat input1
; abc def
; ghI jkl
```

This patch introduces the concept of multiple "match results" per
directive.  In the above example, the first match result for the
CHECK-NEXT directive is the failed match, for which the annotation
shows the search range.  The second match result is the fuzzy match.
Later patches will introduce other cases of multiple match results per
directive.

When colors are enabled, `?` is colored magenta.  That is, it doesn't
indicate the actual error, which a red `X~~` marker indicates, but its
color suggests it's closely related.

Reviewed By: george.karpenkov, probinson

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

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

[FileCheck] Annotate input dump (1/7)

Extend FileCheck to dump its input annotated with FileCheck's
diagnostics: errors, good matches if -v, and additional information if
-vv.  The goal is to make it easier to visualize FileCheck's matching
behavior when debugging.

Each patch in this series implements input annotations for a
particular category of FileCheck diagnostics.  While the first few
patches alone are somewhat useful, the annotations become much more
useful as later patches implement annotations for -v and -vv
diagnostics, which show the matching behavior leading up to the error.

This first patch implements boilerplate plus input annotations for
error diagnostics reporting that no matches were found for a
directive.  These annotations mark the search ranges of the failed
directives.  Instead of using the usual `^~~`, which is used by later
patches for good matches, these annotations use `X~~` so that this
category of errors is visually distinct.

For example:

```
$ FileCheck -dump-input=help
The following description was requested by -dump-input=help to
explain the input annotations printed by -dump-input=always and
-dump-input=fail:

  - L:     labels line number L of the input file
  - T:L    labels the match result for a pattern of type T from line L of
           the check file
  - X~~    marks search range when no match is found
  - colors error

If you are not seeing color above or in input dumps, try: -color

$ FileCheck -v -dump-input=always check1 < input1 |& sed -n '/^Input file/,$p'
Input file: <stdin>
Check file: check1

-dump-input=help describes the format of the following dump.

Full input was:
<<<<<<
        1: ; abc def
        2: ; ghI jkl
next:3     X~~~~~~~~ error: no match found
>>>>>>

$ cat check1
CHECK: abc
CHECK-SAME: def
CHECK-NEXT: ghi
CHECK-SAME: jkl

$ cat input1
; abc def
; ghI jkl
```

Some additional details related to the boilerplate:

* Enabling: The annotated input dump is enabled by `-dump-input`,
  which can also be set via the `FILECHECK_OPTS` environment variable.
  Accepted values are `help`, `always`, `fail`, or `never`.  As shown
  above, `help` describes the format of the dump.  `always` is helpful
  when you want to investigate a successful FileCheck run, perhaps for
  an unexpected pass. `-dump-input-on-failure` and
  `FILECHECK_DUMP_INPUT_ON_FAILURE` remain as a deprecated alias for
  `-dump-input=fail`.

* Diagnostics: The usual diagnostics are not suppressed in this mode
  and are printed first.  For brevity in the example above, I've
  omitted them using a sed command.  Sometimes they're perfectly
  sufficient, and then they make debugging quicker than if you were
  forced to hunt through a dump of long input looking for the error.
  If you think they'll get in the way sometimes, keep in mind that
  it's pretty easy to grep for the start of the input dump, which is
  `<<<`.

* Colored Annotations: The annotated input is colored if colors are
  enabled (enabling colors can be forced using -color).  For example,
  errors are red.  However, as in the above example, colors are not
  vital to reading the annotations.

I don't know how to test color in the output, so any hints here would
be appreciated.

Reviewed By: george.karpenkov, zturner, probinson

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

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

[X86] Add baseline tests for D55780

This adds tests for (add (umax X, C), -C) as part of fixing PR40053

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

hwasan: Move ctor into a comdat.

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

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

[VFS] Add isLocal to ProxyFileSystem and add unit tests.

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

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

[X86][SSE] Improve immediate vector shift known bits handling.

Convert VSRAI to VSRLI is the sign bit is known zero and improve KnownBits output for all shift instruction.

Fixes the poor codegen comments in D55768.

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

[WebAssembly] Fix assembler parsing of br_table.

Summary:
We use `variable_ops` in the tablegen defs to denote the list of
branch targets in `br_table`, but unlike other uses of `variable_ops`
(e.g. call) the these branch targets need to actually be encoded in the
instruction. The existing tables for `variable_ops` cause not operands
to be accepted by the assembly matcher.

Following the example of ARM:
https://github.com/llvm-mirror/llvm/blob/2cc0a7da876c1d8c32775b0119e1e15aaa759b9e/lib/Target/ARM/ARMInstrInfo.td#L550-L555
we introduce a new operand type to capture this list, and we use the
same {} syntax as ARM as well to differentiate them from regular
integer operands.

Also removed definition and use of TSFlags in tablegen defs, since
`br_table` now has a non-variable_ops immediate operand, so the
previous logic of only the variable_ops arguments being labels didn't
make sense anymore.

Reviewers: dschuff, aheejin, sunfish

Subscribers: javed.absar, sbc100, jgravelle-google, kristof.beyls, llvm-commits

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

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

[X86] Add T1MSKC and TZMSK to isDefConvertible used by optimizeCompareInstr.

These seem to have been missed when the other TBM instructions were added.

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

[codeview] Flush labels before S_DEFRANGE* fragments

This was a pre-existing bug that could be triggered with assembly like
this:
  .p2align 2
  .LtmpN:
  .cv_def_range "..."

I noticed this when attempting to change clang to emit aligned symbol
records.

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

[X86][SSE] Split SimplifyDemandedBitsForTargetNode X86ISD::VSRLI/VSRAI handling.

First step towards adding more capable combines to fix comments in D55768.

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

[AggressiveInstCombine] convert rotate with guard branch into funnel shift (PR34924)

Now, that we have funnel shift intrinsics, it should be safe to convert this form of rotate to it.
In the worst case (a target that doesn't have rotate instructions), we will expand this into a
branch-less sequence of ALU ops (neg/and/and/lshr/shl/or) in the backend, so it's still very
likely to be a perf improvement over the original code.

The motivating source code pattern for this is shown in:
https://bugs.llvm.org/show_bug.cgi?id=34924

Background:
I looked at several different options before deciding where to try this - instcombine, simplifycfg,
CGP - because it doesn't fit cleanly anywhere AFAIK.

The backend (CGP, SDAG, GlobalIsel?) is too late for what we're trying to accomplish. We want to
have the IR converted before we reach things like vectorization because the reduced code can make a
loop much simpler to transform.

Technically, this could be included in instcombine, but it's a large pattern match that includes
control-flow, so it just felt wrong to stuff into there (although I have a draft of that patch).
Similarly, this could be part of simplifycfg, but all of this pattern matching is a stretch.

So we're left with our relatively new dumping ground for homeless transforms: aggressive-instcombine.
This only runs at -O3, but that seems like a reasonable limitation given that source code has many
options to avoid this pattern (including the recently added clang intrinsics for rotates).

I'm including a PhaseOrdering test because we require the teamwork of 3 passes (aggressive-instcombine,
instcombine, simplifycfg) to get this into the minimal IR form that we want. That test shows a bug
with the new pass manager that's independent of this change (but it will be masked if we canonicalize
harder to funnel shift intrinsics in instcombine).

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

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

DebugInfo: Update gold plugin tests due to CU attribute reordering in r349207

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

[SDAG] Clarify the origin of chain in REG_SEQUENCE in comment, NFC

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

[SelectionDAG] Fix noop detection for vectors in AssertZext/AssertSext in getNode

The assertion type is always supposed to be a scalar type. So if the result VT of the assertion is a vector, we need to get the scalar VT before we can compare them.

Similarly for the assert above it.

I don't have a test case because I don't know of any place we violate this today. A coworker found this while trying to use r347287 on the 6.0 branch without also having r336868

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