[yaml2obj] Set p_align to the maximum sh_addralign of contained sections

The address difference between two sections in a PT_LOAD is a constant.
Consider a hypothetical case (pagesize can be very small, say, 4).

```
.text     sh_addralign=4
.text.hot sh_addralign=16
```

If we set p_align to 4, the PT_LOAD will be loaded at an address which
is a multiple of 4. The address of .text.hot is guaranteed to be a
multiple of 4, but not necessarily a multiple of 16.

This patch deletes the constraint

  if (SHeader->sh_offset == PHeader.p_offset)

Reviewed By: grimar, jhenderson

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

llvm-svn: 371501

[DWARF] Add a unit test for DWARFUnit::getLength().

This is a follow-up of rL369529, where the return value of
DWARFUnit::getLength() was changed from uint32_t to uint64_t.
The test checks that a unit header with Length > 4G can be successfully
parsed and the value of the Length field is not truncated.

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

llvm-svn: 371499

[Alignment] Use Align for TargetLowering::MinStackArgumentAlignment

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: sdardis, nemanjai, hiraditya, kbarton, jrtc27, MaskRay, atanasyan, jsji, llvm-commits

Tags: #llvm

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

llvm-svn: 371498

Revert Remove REQUIRES:shell from tests that pass for me on Windows

This reverts r371478 (git commit a9980f60ce083fa6d5fd03c12c58ca0b293e3d60)

llvm-svn: 371497

[RISCV] Make -march=rv{32,64}gc the default in RISC-V Linux

This is the logical follow-up of D65634.

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

llvm-svn: 371496

[clangd] some tweaks on the vscode readme, NFC

llvm-svn: 371495

[RISCV] Default to ilp32d/lp64d in RISC-V Linux

When running clang as a native compiler in RISC-V Linux the flag
-mabi=ilp32d / -mabi=lp64d is always mandatory. This change makes it the
default there.

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

llvm-svn: 371494

[LegalizeTypes] Teach SoftenFloatOp_SELECT_CC to handle operand 2 or 3 being softened.

This can only happen on X86 when fp128 is a legal type, but we
go through softening to generate libcalls. This causes fp128 to
be softened to fp128 instead of an integer type. This can be
removed if D67128 lands.

llvm-svn: 371493

[RISCV] Move architecture parsing code into its own function

I plan to reuse it in a later patch.

This is almost NFC except a small change in control flow when diagnosing
+d without +f.

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

llvm-svn: 371492

[LLDB] FreeBSD fix new SetFile call.

llvm-svn: 371491

gn build: Merge r371488

llvm-svn: 371489

Revert "clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM"

This reverts commit r371484: this broke sanitizer-x86_64-linux-fast bot.

llvm-svn: 371488

[X86] Add broadcast load unfolding support for VCMPPS/PD.

llvm-svn: 371487

[X86] Add broadcast load unfold tests for VCMPPS/PD.

llvm-svn: 371486

gn build: Merge r371484

llvm-svn: 371485

clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

This patch contains the basic functionality for reporting potentially
incorrect usage of __builtin_expect() by comparing the developer's
annotation against a collected PGO profile. A more detailed proposal and
discussion appears on the CFE-dev mailing list
(http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a
prototype of the initial frontend changes appear here in D65300

We revised the work in D65300 by moving the misexpect check into the
LLVM backend, and adding support for IR and sampling based profiles, in
addition to frontend instrumentation.

We add new misexpect metadata tags to those instructions directly
influenced by the llvm.expect intrinsic (branch, switch, and select)
when lowering the intrinsics. The misexpect metadata contains
information about the expected target of the intrinsic so that we can
check against the correct PGO counter when emitting diagnostics, and the
compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight.
We use these branch weight values to determine when to emit the
diagnostic to the user.

A future patch should address the comment at the top of
LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and
UnlikelyBranchWeight values into a shared space that can be accessed
outside of the LowerExpectIntrinsic pass. Once that is done, the
misexpect metadata can be updated to be smaller.

In the long term, it is possible to reconstruct portions of the
misexpect metadata from the existing profile data. However, we have
avoided this to keep the code simple, and because some kind of metadata
tag will be required to identify which branch/switch/select instructions
are influenced by the use of llvm.expect

Patch By: paulkirth
Differential Revision: https://reviews.llvm.org/D66324

llvm-svn: 371484

[PowerPC][NFC] Update test assertions using update_llc_test_checks.py

Summary:
This patch is made due to https://reviews.llvm.org/rL371289 where typo
fixes failed.

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

llvm-svn: 371483

Revert [git-llvm] Do not reinvent `@{upstream}`

This reverts r371290 (git commit 7faffd544b16f851a632d6b8f93e3c8485ff34bb)

The change wasnt NFC and broke some users' workflow. Reverting while figuring
out the best alternative to move forward.

llvm-svn: 371480

gn build: Merge r371466

llvm-svn: 371479

Remove REQUIRES:shell from tests that pass for me on Windows

I see in the history for some of these tests REQUIRES:shell was used as
a way to disable tests on Windows because they are flaky there. I tried
not to re-enable such tests, but it's possible that I missed some and
this will re-enable flaky tests on Windows. If so, we should disable
them with UNSUPPORTED:system-windows and add a comment that they are
flaky there. So far as I can tell, the lit internal shell is capable of
running all of these tests, and we shouldn't use REQUIRES:shell as a
proxy for Windows.

llvm-svn: 371478

gn build: (manually) merge r371429

llvm-svn: 371477

Fix crash mangling an explicit lambda non-type template parameter pack
that is not a pack expansion.

llvm-svn: 371476

[llvm][ADT][NFC] Add test for makeArrayRef(std::array)

llvm-svn: 371475

[Utility] Replace `lldb_private::CleanUp` by `llvm::scope_exit`

This removes the CleanUp class and replaces its usages with llvm's
ScopeExit, which has similar semantics.

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

llvm-svn: 371474

Remove some unnecessary REQUIRES: shell lines

This means these tests will run on Windows. Replace one with
UNSUPPORTED: system-windows.

llvm-svn: 371473

[Expression] Remove unused header from LLVMUserExpression

llvm-svn: 371472

AMDGPU/GlobalISel: Fix insert point when lowering fminnum/fmaxnum

llvm-svn: 371471

[Symbol] Give ClangASTContext a PersistentExpressionState instead of a ClangPersistentVariables

ClangASTContext doesn't use m_persistent_variables in a way specific to
ClangPersistentVariables. Therefore, it should hold a unique pointer to
PersistentExpressionState instead of a ClangPersistentVariablesUP.
This also prevents you from pulling in a plugin header when including
ClangASTContext.h

Doing this exposed an implicit dependency in ObjCLanguage that was
corrected by including ClangModulesDeclVendor.h

llvm-svn: 371470

Fix incorrect demangling of call operator of lambda with explicit
template parameters due to registering template parameters twice.

llvm-svn: 371469

PR43242: Fix crash when typo-correcting to an operator() that should not
have been visible.

llvm-svn: 371468

AMDGPU/GlobalISel: Rename MIRBuilder to B. NFC

Reviewers: arsenm

Reviewed By: arsenm

Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, rovka, dstuttard, tpr, t-tye, hiraditya, Petar.Avramovic, llvm-commits

Tags: #llvm

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

llvm-svn: 371467

[Windows] Replace TrapUnreachable with an int3 insertion pass

This is an alternative to D66980, which was reverted. Instead of
inserting a pseudo instruction that optionally expands to nothing, add a
pass that inserts int3 when appropriate after basic block layout.

Reviewers: hans

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

llvm-svn: 371466

[GlobalISel]: Fix a bug where we could dereference None

getConstantVRegVal returns None when dealing with constants > 64 bits.
Don't assume we always have a value in GISelKnownBits.

llvm-svn: 371465

Simplify demangler rule for lambda-expressions to match discussion on
cxx-abi list.

llvm-svn: 371462

LangRef: mention MSan's problem with speculative conditional branches.

Summary:
This short blurb aims to disallow optimizations like we had to revert
(under MSan) in
  https://reviews.llvm.org/D21165
  https://bugs.llvm.org/show_bug.cgi?id=28054
  https://reviews.llvm.org/D67205

Reviewers: vitalybuka, efriedma

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 371461

Revert "[Reproducer] Add a `cont` to ModuleCXX.test"

This should no longer be necessary after r371459.

llvm-svn: 371460

[Reproducer] Disconnect when the replay server is out of packets.

This is a fix for the issue described in r371144.

> On more than one occasion I've found this test got stuck during replay
> while waiting for a packet from debugserver when the debugger was in
> the process of being destroyed.

When the replay server is out of packets we should just disconnect so
the debugger doesn't have to do any cleanup that it wouldn't do during
capture.

llvm-svn: 371459

[mips] Make another set of test cases more tolerant to exact symbol addresses. NFC

llvm-svn: 371458

Fix ELF core file memory reading for PT_LOAD program headers with no p_filesz

Prior to this fix, ELF files might contain PT_LOAD program headers that had a valid p_vaddr, and a valid file p_offset, but the p_filesz would be zero. For example in llvm-project/lldb/test/testcases/functionalities/postmortem/elf-core/thread_crash/linux-i386.core we see:

Program Headers:
Index   p_type           p_flags    p_offset           p_vaddr            p_paddr            p_filesz           p_memsz            p_align
======= ---------------- ---------- ------------------ ------------------ ------------------ ------------------ ------------------ ------------------
[    0] PT_NOTE          0x00000000 0x0000000000000474 0x0000000000000000 0x0000000000000000 0x0000000000001940 0x0000000000000000 0x0000000000000000
[    1] PT_LOAD          0x00000005 0x0000000000002000 0x0000000008048000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000
[    2] PT_LOAD          0x00000004 0x0000000000002000 0x000000000804b000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[    3] PT_LOAD          0x00000006 0x0000000000002000 0x000000000804c000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[    4] PT_LOAD          0x00000006 0x0000000000002000 0x0000000009036000 0x0000000000000000 0x0000000000000000 0x0000000000025000 0x0000000000001000
[    5] PT_LOAD          0x00000000 0x0000000000002000 0x00000000f63a1000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[    6] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f63a2000 0x0000000000000000 0x0000000000000000 0x0000000000800000 0x0000000000001000
[    7] PT_LOAD          0x00000000 0x0000000000002000 0x00000000f6ba2000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[    8] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f6ba3000 0x0000000000000000 0x0000000000000000 0x0000000000804000 0x0000000000001000
[    9] PT_LOAD          0x00000005 0x0000000000002000 0x00000000f73a7000 0x0000000000000000 0x0000000000000000 0x00000000001b1000 0x0000000000001000
[   10] PT_LOAD          0x00000004 0x0000000000002000 0x00000000f7558000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000
[   11] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f755a000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[   12] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f755b000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000
[   13] PT_LOAD          0x00000005 0x0000000000002000 0x00000000f755e000 0x0000000000000000 0x0000000000000000 0x0000000000019000 0x0000000000001000
[   14] PT_LOAD          0x00000004 0x0000000000002000 0x00000000f7577000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[   15] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f7578000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[   16] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f7579000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000
[   17] PT_LOAD          0x00000005 0x0000000000002000 0x00000000f757b000 0x0000000000000000 0x0000000000000000 0x000000000001c000 0x0000000000001000
[   18] PT_LOAD          0x00000004 0x0000000000002000 0x00000000f7597000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[   19] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f7598000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[   20] PT_LOAD          0x00000005 0x0000000000002000 0x00000000f7599000 0x0000000000000000 0x0000000000000000 0x0000000000053000 0x0000000000001000
[   21] PT_LOAD          0x00000004 0x0000000000002000 0x00000000f75ec000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[   22] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f75ed000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[   23] PT_LOAD          0x00000005 0x0000000000002000 0x00000000f75ee000 0x0000000000000000 0x0000000000000000 0x0000000000176000 0x0000000000001000
[   24] PT_LOAD          0x00000004 0x0000000000002000 0x00000000f7764000 0x0000000000000000 0x0000000000000000 0x0000000000006000 0x0000000000001000
[   25] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f776a000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[   26] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f776b000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000
[   27] PT_LOAD          0x00000006 0x0000000000002000 0x00000000f778a000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000
[   28] PT_LOAD          0x00000004 0x0000000000002000 0x00000000f778c000 0x0000000000000000 0x0000000000002000 0x0000000000002000 0x0000000000001000
[   29] PT_LOAD          0x00000005 0x0000000000004000 0x00000000f778e000 0x0000000000000000 0x0000000000002000 0x0000000000002000 0x0000000000001000
[   30] PT_LOAD          0x00000005 0x0000000000006000 0x00000000f7790000 0x0000000000000000 0x0000000000000000 0x0000000000022000 0x0000000000001000
[   31] PT_LOAD          0x00000004 0x0000000000006000 0x00000000f77b3000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[   32] PT_LOAD          0x00000006 0x0000000000006000 0x00000000f77b4000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[   33] PT_LOAD          0x00000006 0x0000000000006000 0x00000000ffa25000 0x0000000000000000 0x0000000000000000 0x0000000000022000 0x0000000000001000
Prior to this fix if users tried to read memory from one of these addresses like 0x8048000, they would end up incorrectly reading from the next memory region that actually had a p_filesz which would be 0x00000000f778c000 in this case. This fix correctly doesn't include program headers with zero p_filesz in the ProcessELFCore::m_core_aranges that is used to read memory. I found two cores files that have this same issue and added tests.

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

llvm-svn: 371457

[Tests] Fix a typo in a test

llvm-svn: 371456

[Tests] Precommit test case for D67372

llvm-svn: 371455

Fix MSVC "not all control paths return a value" warning. NFCI.

llvm-svn: 371454

[UBSan] Follow up fix for r371442.

Reviewers: vitalybuka, hctim, Dor1s

Reviewed By: Dor1s

Subscribers: delcypher, #sanitizers, llvm-commits

Tags: #llvm, #sanitizers

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

llvm-svn: 371453

[LoopVectorize] Leverage speculation safety to avoid masked.loads

If we're vectorizing a load in a predicated block, check to see if the load can be speculated rather than predicated.  This allows us to generate a normal vector load instead of a masked.load.

To do so, we must prove that all bytes accessed on any iteration of the original loop are dereferenceable, and that all loads (across all iterations) are properly aligned.  This is equivelent to proving that hoisting the load into the loop header in the original scalar loop is safe.

Note: There are a couple of code motion todos in the code.  My intention is to wait about a day - to be sure this sticks - and then perform the NFC motion without furthe review.

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

llvm-svn: 371452

[analyzer] NFC: Simplify bug report equivalence classes to not be ilists.

Use a vector of unique pointers instead.

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

llvm-svn: 371451

[analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.

Checkers are now required to specify whether they're creating a
path-sensitive report or a path-insensitive report by constructing an
object of the respective type.

This makes BugReporter more independent from the rest of the Static Analyzer
because all Analyzer-specific code is now in sub-classes.

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

llvm-svn: 371450

[Tests] Add anyextend tests for unordered atomics

Motivated by work on changing our representation of unordered atomics in SelectionDAG, but as an aside, all our lowerings for O3 are terrible.  Even the ones which ignore the atomicity.

llvm-svn: 371449

Relax opcode checks in test to check for only a number instead of a specific number.

llvm-svn: 371447

[TSan] Add AnnotateIgnoreReadsBegin declaration to tsan/test.h

Declare the family of AnnotateIgnore[Read,Write][Begin,End] TSan
annotations in compiler-rt/test/tsan/test.h so that we don't have to
declare them separately in every test that needs them.  Replace usages.

Leave usages that explicitly test the annotation mechanism:
  thread_end_with_ignore.cpp
  thread_end_with_ignore3.cpp

llvm-svn: 371446

[SDAG] Add a isSimple cover functon to MemSDNode, just as we have in IR/MI [NFC]

Uses are in reviews D66322 and D66318.  Submitted separately to control rebuild times.

llvm-svn: 371445

[Driver] Handle default case in refactored addOpenMPRuntime

Summary:
Appease failed builds (due to -Werror and -Wswitch) where OMPRT_Unknown
is not handled in the switch statement (even though it's handled by the
early exit).

This fixes -Wswitch triggered by r371442.

Reviewers: srhines, danalbert, jdoerfert

Subscribers: guansong, cfe-commits

Tags: #clang

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

llvm-svn: 371444

[Remarks] Fix warning for uint8_t < 0 comparison

http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/19109/steps/build-stage1-compiler/logs/stdio

llvm-svn: 371443

[UBSan] Do not overwrite the default print_summary sanitizer option.

Summary:
This option is true by default in sanitizer common. The default
false value was added a while ago without any reasoning in
https://github.com/llvm-mirror/compiler-rt/commit/524e934112a593ac081bf2b05aa0d60a67987f05

so, presumably it's safe to remove for consistency.

Reviewers: hctim, samsonov, morehouse, kcc, vitalybuka

Reviewed By: hctim, samsonov, vitalybuka

Subscribers: delcypher, #sanitizers, llvm-commits, kcc

Tags: #llvm, #sanitizers

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

llvm-svn: 371442

Introduce infrastructure for an incremental port of SelectionDAG atomic load/store handling

This is the first patch in a large sequence. The eventual goal is to have unordered atomic loads and stores - and possibly ordered atomics as well - handled through the normal ISEL codepaths for loads and stores. Today, there handled w/instances of AtomicSDNodes. The result of which is that all transforms need to be duplicated to work for unordered atomics. The benefit of the current design is that it's harder to introduce a silent miscompile by adding an transform which forgets about atomicity.  See the thread on llvm-dev titled "FYI: proposed changes to atomic load/store in SelectionDAG" for further context.

Note that this patch is NFC unless the experimental flag is set.

The basic strategy I plan on taking is:

    introduce infrastructure and a flag for testing (this patch)
    Audit uses of isVolatile, and apply isAtomic conservatively*
    piecemeal conservative* update generic code and x86 backedge code in individual reviews w/tests for cases which didn't check volatile, but can be found with inspection
    flip the flag at the end (with minimal diffs)
    Work through todo list identified in (2) and (3) exposing performance ops

(*) The "conservative" bit here is aimed at minimizing the number of diffs involved in (4). Ideally, there'd be none. In practice, getting it down to something reviewable by a human is the actual goal. Note that there are (currently) no paths which produce LoadSDNode or StoreSDNode with atomic MMOs, so we don't need to worry about preserving any behaviour there.

We've taken a very similar strategy twice before with success - once at IR level, and once at the MI level (post ISEL).

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

llvm-svn: 371441

AMDGPU/GlobalISel: Legalize G_BUILD_VECTOR v2s16

Handle it the same way as G_BUILD_VECTOR_TRUNC. Arguably only
G_BUILD_VECTOR_TRUNC should be legal for this, but G_BUILD_VECTOR will
probably be more convenient in most cases.

llvm-svn: 371440

[TSan] Add interceptors for mach_vm_[de]allocate

I verified that the test is red without the interceptors.

rdar://40334350

Reviewed By: kubamracek, vitalybuka

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

llvm-svn: 371439

AMDGPU: Make VReg_1 size be 1

This was getting chosen as the preferred 32-bit register class based
on how TableGen selects subregister classes.

llvm-svn: 371438

[Driver] Add -static-openmp driver option

Summary:
For Gnu, FreeBSD and NetBSD, this option forces linking with the static
OpenMP host runtime (similar to -static-libgcc and -static-libstdcxx).

Android's NDK will start the shared OpenMP runtime in addition to the static
libomp.  In this scenario, the linker will prefer to use the shared library by
default.  Add this option to enable linking with the static libomp.

Reviewers: Hahnfeld, danalbert, srhines, joerg, jdoerfert

Subscribers: guansong, cfe-commits

Tags: #clang

Fixes https://github.com/android-ndk/ndk/issues/1028

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

llvm-svn: 371437

AMDGPU/GlobalISel: Select llvm.amdgcn.class

Also fixes missing SubtargetPredicate on f16 class instructions.

llvm-svn: 371436

AMDGPU/GlobalISel: Select fmed3

llvm-svn: 371435

[IfConversion] Correctly handle cases where analyzeBranch fails.

If analyzeBranch fails, on some targets, the out parameters point to
some blocks in the function. But we can't use that information, so make
sure to clear it out.  (In some places in IfConversion, we assume that
any block with a TrueBB is analyzable.)

The change to the testcase makes it trigger a bug on builds without this
fix: IfConvertDiamond tries to perform a followup "merge" operation,
which isn't legal, and we somehow end up with a branch to a deleted MBB.
I'm not sure how this doesn't crash the compiler.

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

llvm-svn: 371434

[x86] add test for false dependency with minsize (PR43239); NFC

llvm-svn: 371433

AMDGPU: Use PatFrags to allow selecting custom nodes or intrinsics

This enables GlobalISel to handle various intrinsics. The custom node
pattern will be ignored, and the intrinsic will work. This will also
allow SelectionDAG to directly select the intrinsics, but as they are
all custom lowered to the nodes, this ends up leaving dead code in the
table.

Eventually either GlobalISel should add the equivalent of custom nodes
equivalent, or intrinsics should be directly used. These each have
different tradeoffs.

There are a few more to handle, but these are easy to handle
ones. Some others fail for other reasons.

llvm-svn: 371432

[SelectionDAG] Remove ISD::FP_ROUND_INREG

I don't think anything in tree creates this node. So all of this
code appears to be dead.

Code coverage agrees
http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/workspace/clang-stage2-coverage-R/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp.html

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

llvm-svn: 371431

[X86] Allow _MM_FROUND_CUR_DIRECTION and _MM_FROUND_NO_EXC to be used together on instructions that only support SAE and not embedded rounding.

Current for SAE instructions we only allow _MM_FROUND_CUR_DIRECTION(bit 2) or _MM_FROUND_NO_EXC(bit 3) to be used as the immediate passed to the inrinsics. But these instructions don't perform rounding so _MM_FROUND_CUR_DIRECTION is just sort of a default placeholder when you don't want to suppress exceptions. Using _MM_FROUND_NO_EXC by itself is really bit equivalent to (_MM_FROUND_NO_EXC | _MM_FROUND_TO_NEAREST_INT) since _MM_FROUND_TO_NEAREST_INT is 0. Since we aren't rounding on these instructions we should also accept (_MM_FROUND_CUR_DIRECTION | _MM_FROUND_NO_EXC) as equivalent to (_MM_FROUND_NO_EXC). icc allows this, but gcc does not.

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

llvm-svn: 371430

[Remarks] Add parser for bitstream remarks

The bitstream remark serializer landed in r367372.

This adds a bitstream remark parser that parser bitstream remark files
to llvm::remarks::Remark objects through the RemarkParser interface.

A few interesting things to point out:

* There are parsing helpers to parse the different types of blocks
* The main parsing helper allows us to parse remark metadata and open an
external file containing the encoded remarks
* This adds a dependency from the Remarks library to the BitstreamReader
library
* The testing strategy is to create a remark entry through YAML, parse
it, serialize it to bitstream, parse that back and compare the objects.
* There are close to no tests for malformed bitstream remarks, due to
the lack of textual format for the bitstream format.
* This adds a new C API for parsing bitstream remarks:
LLVMRemarkParserCreateBitstream.
* This bumps the REMARKS_API_VERSION to 1.

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

llvm-svn: 371429

[mips] Fix decoding of microMIPS JALX instruction

microMIPS jump and link exchange instruction stores a target in a
26-bits field. Despite other microMIPS JAL instructions these bits
are target address shifted right 2 bits [1]. The patch fixes the
JALX instruction decoding and uses 2-bit shift.

[1] MIPS Architecture for Programmers Volume II-B: The microMIPS32 Instruction Set

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

llvm-svn: 371428

AMDGPU: Move MnemonicAlias out of instruction def hierarchy

Unfortunately MnemonicAlias defines a "Predicates" field just like an
instruction or pattern, with a somewhat different interpretation.

This ends up overriding the intended Predicates set by
PredicateControl on the pseudoinstruction defintions with an empty
list. This allowed incorrectly selecting instructions that should have
been rejected due to the SubtargetPredicate from patterns on the
instruction definition.

This does remove the divergent predicate from the 64-bit shift
patterns, which were already not used for the 32-bit shift, so I'm not
sure what the point was. This also removes a second, redundant copy of
the 64-bit divergent patterns.

llvm-svn: 371427

[SLP] add test for over-vectorization (PR33958); NFC

llvm-svn: 371426

[GlobalISel][AArch64] Handle tail calls with non-void return types

Just return once you emit the call, which is exactly what SelectionDAG does in
this situation.

Update call-translator-tail-call.ll.

Also update dllimport.ll to show that we tail call here in GISel again. Add
-verify-machineinstrs to the GISel line too, to defend against verifier
failures.

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

llvm-svn: 371425

AMDGPU/GlobalISel: Implement LDS G_GLOBAL_VALUE

Handle the simple case that lowers to a constant.

llvm-svn: 371424

AMDGPU/GlobalISel: Legalize G_BUILD_VECTOR_TRUNC

Treat this as legal on gfx9 since it can use S_PACK_* instructions for
this.

This isn't used by anything yet. The same will probably apply to
16-bit G_BUILD_VECTOR without the trunc.

llvm-svn: 371423

[clangd] Attempt to fix failing Windows buildbots.

The assertion is failing on Windows, probably because path separator is different.

For the failure see:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/28072/steps/test/logs/stdio

llvm-svn: 371422

Revert "[MachineCopyPropagation] Remove redundant copies after TailDup via machine-cp"

This reverts commit 371359. I'm suspecting a miscompile, I posted a
reproducer to https://reviews.llvm.org/D65267.

llvm-svn: 371421

[yaml2obj] Simplify p_filesz/p_memsz computing

This fixes a bug as well. When "FileSize:" (p_filesz) is specified and
different from the actual value, the following code probably should not
use PHeader.p_filesz:

  if (SHeader->sh_offset == PHeader.p_offset + PHeader.p_filesz)
    PHeader.p_memsz += SHeader->sh_size;

Reviewed By: jhenderson

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

llvm-svn: 371420

[ARM] Fix loads and stores for predicate vectors

These predicate vectors can usually be loaded and stored with a single
instruction, a VSTR_P0. However this instruction will store the entire P0
predicate, 16 bits, zeroextended to 32bits. Each lane of the the
v4i1/v8i1/v16i1 representing 4/2/1 bits.

As far as I understand, when llvm says "store this v4i1", it really does need
to store 4 bits (or 8, that being the size of a byte, with this bottom 4 as the
interesting bits). For example a bitcast from a v8i1 to a i8 is defined as a
store followed by a load, which is how the code is expanded.

So this instead lowers the v4i1/v8i1 load/store through some shuffles to get
the bits into the correct positions. This, as you might imagine, is not as
efficient as a single instruction. But I believe it is needed for correctness.
v16i1 equally should not load/store 32bits, only storing the 16bits of data.
Stack loads/stores are still using the VSTR_P0 (as can be seen by the test not
changing). This is fine as they are self-consistent, it is only "externally
observable loads/stores" (from our point of view) that need to be corrected.

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

llvm-svn: 371419

AMDGPU/GlobalISel: Select atomic loads

A new check for an explicitly atomic MMO is needed to avoid
incorrectly matching pattern for non-atomic loads

llvm-svn: 371418

LLDB - Simplify GetProgramFileSpec

Reviewers: zturner, emaste

Reviewed By: emaste

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

llvm-svn: 371417

AMDGPU/GlobalISel: Fix RegBankSelect for unaligned, uniform constant loads

llvm-svn: 371416

Fix typo in comment noticed in D60295. NFCI.

llvm-svn: 371415

AMDGPU/GlobalISel: Fix regbankselect for uniform extloads

There are no scalar extloads.

llvm-svn: 371414

AMDGPU: Remove code address space predicates

Fixes 8-byte, 8-byte aligned LDS loads. 16-byte case still broken due
to not be reported as legal.

llvm-svn: 371413

AMDGPU/GlobalISel: Select G_PTR_MASK

llvm-svn: 371412

AMDGPU/GlobalISel: Fix reg bank for uniform LDS loads

The pointer is always a VGPR. Also fix hardcoding the pointer size to
64.

llvm-svn: 371411

[NFC] Add aacps bitfields access test

llvm-svn: 371410

AMDGPU/GlobalISel: Use known bits for selection

llvm-svn: 371409

[clangd] Use pre-populated mappings for standard symbols

Summary:
This takes ~5% of time when running clangd unit tests.

To achieve this, move mapping of system includes out of CanonicalIncludes
and into a separate class

Reviewers: sammccall, hokein

Reviewed By: sammccall

Subscribers: MaskRay, jkorous, arphaman, kadircet, jfb, cfe-commits

Tags: #clang

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

llvm-svn: 371408

AMDGPU/GlobalISel: Legalize wavefrontsize intrinsic

llvm-svn: 371407

AMDGPU/GlobalISel: Try generated matcher before add/sub code

This will allow optimization patterns which fold adds away to work.

llvm-svn: 371406

[ARM] Remove some spurious MVE reduction instructions.

The family of 'dual-accumulating' vector multiply-add instructions
(VMLADAV, VMLALDAV and VRMLALDAVH) can all operate on both signed and
unsigned integer types, and they all have an 'exchange' variant (with
an X in the name) that modifies which pairs of vector lanes in the two
inputs are multiplied together. But there's a clause in the spec that
says that the X variants //don't// operate on unsigned integer types,
only signed. You can have X, or unsigned, or neither, but not both.

We didn't notice that clause when we implemented the MC support for
these instructions, so LLVM believes that things like VMLADAVX.U8 do
exist, contradicting the spec. Here I fix that by conditioning them
out in Tablegen.

In order to do that, I've reversed the nesting order of the Tablegen
multiclasses for those instructions. Previously, the innermost
multiclass generated the X and not-X variants, and the one outside
that generated the A and not-A variants. Now X is done by the outer
multiclass, which allows me to bypass that one when I only want the
two not-X variants.

Changing the multiclass nesting order also changes the names of the
instruction ids unless I make a special effort not to. I decided that
while I was changing them anyway I'd make them look nicer; so now the
instructions have names like MVE_VMLADAVs32 or MVE_VMLADAVaxs32,
instead of cumbersome _noacc_noexch suffixes.

The corresponding multiply-subtract instructions are unaffected. Those
don't accept unsigned types at all, either in the spec or in LLVM.

Reviewers: ostannard, dmgreen

Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 371405

AMDGPU/GlobalISel: Remove dead patterns

llvm-svn: 371404

Merge note_ovl_builtin_candidate diagnostics; NFC

There is no difference between the unary and binary case, so
merge them.

llvm-svn: 371403

[clangd] Add a new highlighting kind for typedefs

Summary:
We still attempt to highlight them as underlying types, but fallback to
the generic 'typedef' highlighting kind if the underlying type is too
complicated.

Reviewers: hokein

Reviewed By: hokein

Subscribers: nridge, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 371402

[NFC][InstCombine] Fixup test i added in rL371352.

llvm-svn: 371401

compiler-rt: use fp_t instead of long double, for consistency

Most builtins accepting or returning long double use the fp_t typedef.
Change the remaining few cases to do so.

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

llvm-svn: 371400

[DFAPacketizer] Reapply: Track resources for packetized instructions

Reapply with fix to reduce resources required by the compiler - use
unsigned[2] instead of std::pair. This causes clang and gcc to compile
the generated file multiple times faster, and hopefully will reduce
the resource requirements on Visual Studio also. This fix is a little
ugly but it's clearly the same issue the previous author of
DFAPacketizer faced (the previous tables use unsigned[2] rather uglily
too).

This patch allows the DFAPacketizer to be queried after a packet is formed to work out which
resources were allocated to the packetized instructions.

This is particularly important for targets that do their own bundle packing - it's not
sufficient to know simply that instructions can share a packet; which slots are used is
also required for encoding.

This extends the emitter to emit a side-table containing resource usage diffs for each
state transition. The packetizer maintains a set of all possible resource states in its
current state. After packetization is complete, all remaining resource states are
possible packetization strategies.

The sidetable is only ~500K for Hexagon, but the extra tracking is disabled by default
(most uses of the packetizer like MachinePipeliner don't care and don't need the extra
maintained state).

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

llvm-svn: 371399

[ELF] nmagic or omagic: don't allocate PT_PHDR or PF_R PT_LOAD for the !hasPhdrsCommands case

```
part.phdrs = script->hasPhdrsCommands() ? script->createPhdrs() : createPhdrs(part);
```

createPhdrs() allocates a PT_PHDR and a PF_R PT_LOAD, which will be
deleted later in LinkerScript::allocateHeaders, but leave a gap between
the program headers and the first section. Don't allocate the segments
to avoid the gap. PT_INTERP is likely not needed as well.

Reviewed By: ruiu

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

llvm-svn: 371398

[Inliner][NFC] Make test less brittle.

Summary:
This tests inlining size thresholds, but relies on the output of running
the full O2 pipeline, making it brittle against changes in unrelated
passes.

Only run the inlining pass and set thresholds on the test RUN line
instead.

Found while investigating D60318.

Reviewers: RKSimon, qcolombet

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 371397

[clang-tidy] Fix bug in bugprone-use-after-move check

Summary:
The bugprone-use-after-move check exhibits false positives for certain uses of
the C++17 if/switch init statements. These false positives are caused by a bug
in the ExprSequence calculations.

This revision adds tests for the false positives and fixes the corresponding
sequence calculation.

Reviewers: gribozavr

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

llvm-svn: 371396

[ARM][MVE] VCTP instruction selection

Add codegen support for vctp{8,16,32}.

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

llvm-svn: 371395