Summary: Add support for ?, DUP, and string initializers, as well as MASM syntax for named data locations.

Reviewers: rnk, thakis

Reviewed By: thakis

Subscribers: merge_guards_bot, hiraditya, llvm-commits

Tags: #llvm

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

Previously we emitted an fmadd and a fmadd+fneg and combined them with a shufflevector. But this doesn't follow the correct exception behavior for unselected elements so the backend can't merge them into the fmaddsub/fmsubadd instructions.

This patch restores the the fmaddsub intrinsics so we don't have two arithmetic operations. We lose out on optimization opportunity in the non-strict FP case, but I don't think this is a big loss. If someone gives us a test case we can look into adding instcombine/dagcombine improvements. I'd rather not have the frontend do completely different things for strict and non-strict.

This still has problems because target specific intrinsics don't support strict semantics yet. We also still have all of the problems with masking. But we at least generate the right instruction in constrained mode now.

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

GCC 9.2 seems to incorrectly issue warning about out of bounds
access. This situation should not happen in any way.

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

https://reviews.llvm.org/D68480 added those headers and made the std module
only usable with C++14 or later as the submodules were not marked as requiring
C++14 or later. This just adds the missing requires directives.

Previously C++ test passes for SPIR-V were put under
test/Dialect/SPIRV. Move them to test/lib/Dialect/SPIRV
to create a better structure.

Also fixed one of the test pass to use new
PassRegistration mechanism.

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

This patch adds bindings to C and Go for
addCoroutinePassesToExtensionPoints, which is used to add coroutine
passes to the correct locations in PassManagerBuilder.

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

This is the second patch as part of https://bugs.llvm.org/show_bug.cgi?id=36544

Merging in the ConstantSDNode variant of FoldConstantArithmetic. After this, I will begin merging in FoldConstantVectorArithmetic

I've ensured this patch can build & pass all lit tests in Windows and Linux environments.

Patch by @justice_adams (Justice Adams)

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

Add checks for triples that don't use mach-o, and unit tests for
everything.

This allows removing instructions without erasing them. They can then be
added somewhere else in the IR using Builder.Insert().

Simply by implementing a few functions I was able to correctly
disassemble a much larger amount of instructions.

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

Noticed by inspection, we shouldn't use FloatDomain directly, we've already bitcast both inputs to MaskVT so select the opcode using that.

Not all operands are correctly disassembled at the moment. This means
that some machine instructions won't have all the necessary operands
set.
To avoid asserting, print an error instead until the necessary support
has been implemented.

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

A number of multiplication instructions (muls, mulsu, fmul, fmuls,
fmulsu) had the wrong register class for an operand. This resulted in
the wrong register being used for the instruction.

Example:

    target datalayout = "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8"
    target triple = "avr-atmel-none"

    define i16 @sliceAppend(i16, i16, i16, i16, i16, i16) addrspace(1) {
      %d = mul i16 %0, %5
      ret i16 %d
    }

The first instruction would be muls r24, r31 before this patch. The r31
should have been r15 if you look at the intermediate forms during
instruction selection / register allocation, but the generated
instruction uses r31. After this patch, an extra movw is inserted to get
%5 in range for muls.

To make sure this bug is fixed everywhere, I checked all instructions
and found that most multiplication instructions suffered from this bug,
which I have fixed with this patch. No other instructions appear to be
affected.

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

Summary:
Function descriptor csect on AIX should be 4 byte align instead of 1 byte align.

Reviewer: daltenty

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

Pass plugins introduced in D61446 do not support dynamic linking on
Windows, hence the option LLVM_${name_upper}_LINK_INTO_TOOLS can only
work being set to "ON". Currently, it defaults to "OFF" such that such
plugins are inoperable by default on Windows. Change the default for
subprojects to follow LLVM_ENABLE_PROJECTS.

Reviewed By: serge-sans-paille, MaskRay

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

Subscribers: llvm-commits

Tags: #llvm

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

We always build all components of libc++ with -std=c++14 anyway

And add llvm-go back to the test dependencies.

No longer necessary now that llvm-go has been brought back.

This reverts commit e8f8873d.

- Avoid using C++11-and-later features in <atomic>:
  Historically, we've supported <atomic> in C++03, so we can't use C++11
  features in that header. This is something we really need to change,
  since our implementation of <atomic> is starting to accumulate technical
  debt because of that.
- Mark a test as unsupported on single threaded systems
- Add missing symbols to the Linux ABI list

I'm hoping to begin improving shuffle combining across different vector sizes, but before that we must ensure that all existing getTargetShuffleInputs calls must bail if the inputs aren't the same size.

Extends the existing support for spilling and restoring the condition
register to the linkage area for 32-bit targets, and enables for AIX.

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

The convention is that the dwp file name is derived from the name of the
file holding the executable code, even if the linked portion of the
debug info is elsewhere (objcopy --only-keep-debug).

Summary: We want to eventually remove it.

Reviewers: EricWF

Subscribers: christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

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

- Add the new symbols to the ABI list on Darwin
- Add XFAIL markup to the tests that require dylib support on older platforms
- Add availability markup for back-deployment

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

Summary: This step is the preparation of allowing lvalue in map/motion clause.

Reviewers: ABataev, jdoerfert

Reviewed By: ABataev

Subscribers: guansong, cfe-commits

Tags: #clang, #openmp

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

This PR enables "XL" C++ ABI in frontend AST to IR codegen. And it is driven by
static init work. The current kind in Clang by default is Generic Itanium, which
has different behavior on static init with IBM xlclang compiler on AIX.

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

D74976 will handle larger vector types, but since SLM doesn't support AVX+ then we will always be extracting from 128-bit vectors so don't need to scale the cost.

This adds infrastructure to print and parse MIR MachineOperand comments.
The motivation for the ARM backend is to print condition code names instead of
magic constants that are difficult to read (for human beings). For example,
instead of this:

  dead renamable $r2, $cpsr = tEOR killed renamable $r2, renamable $r1, 14, $noreg
  t2Bcc %bb.4, 0, killed $cpsr

we now print this:

  dead renamable $r2, $cpsr = tEOR killed renamable $r2, renamable $r1, 14 /* CC::always */, $noreg
  t2Bcc %bb.4, 0 /* CC:eq */, killed $cpsr

This shows that MachineOperand comments are enclosed between /* and */. In this
example, the EOR instruction is not conditionally executed (i.e. it is "always
executed"), which is encoded by the 14 immediate machine operand. Thus, now
this machine operand has /* CC::always */ as a comment. The 0 on the next
conditional branch instruction represents the equal condition code, thus now
this operand has /* CC:eq */ as a comment.

As it is a comment, the MI lexer/parser completely ignores it. The benefit is
that this keeps the change in the lexer extremely minimal and no target
specific parsing needs to be done. The changes on the MIPrinter side are also
minimal, as there is only one target hooks that is used to create the machine
operand comments.

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

Summary:
Implements the @llvm.aarch64.sve.dupq.lane intrinsic.

As specified in the ACLE, the behaviour of:
  svdupq_lane_u64(data, index)

...is identical to:
  svtbl(data, svadd_x(svptrue_b64(),
                      svand_x(svptrue_b64(), svindex_u64(0, 1), 1),
                      index * 2))

If the index is in the range [0,3], the operation is equivalent
to a single DUP (.q) instruction.

Reviewers: sdesmalen, c-rhodes, cameron.mcinally, efriedma, dancgr, rengolin

Reviewed By: sdesmalen

Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, cfe-commits, llvm-commits

Tags: #llvm

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

Change the way that we remove the redundant iteration count code in
the presence of IT blocks. collectLocalKilledOperands has been
introduced to scan an instructions operands, collecting the killed
instructions and then visiting them too. This is used to delete the
code in the preheader which calculates the iteration count. We also
track any IT blocks within the preheader and, if we remove all the
instructions from the IT block, we also remove the IT instruction.
isSafeToRemove is used to remove any redundant uses of the iteration
count within the loop body.

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

The syntax rules for ptr-operator allow attributes after *, &,
&&, therefore we should be able to parse the following:

void fn() {
    void (*[[attr]] x)() = &fn;
    void (&[[attr]] y)() = fn;
    void (&&[[attr]] z)() = fn;
}
However the current logic in TryParsePtrOperatorSeq does not consider
the presence of attributes leading to unexpected parsing errors.

Moreover we should also consider _Atomic a possible qualifier that can
appear after the sequence of attribute specifiers.

Summary:
According to the ACLE the vbrsrq* intrinsics don't accept vectors
with 64-bit elements (and neither does the corresponding VBRSR
instruction).

Reviewers: simon_tatham, dmgreen, MarkMurrayARM, ostannard

Reviewed By: simon_tatham

Subscribers: kristof.beyls, cfe-commits

Tags: #clang

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

SLM/GLM is still a mess so not all of them have been updated yet.