Given that OpState already implicit converts to Operator*, this seems reasonable.

The alternative would be to add more functions to OpState which forward to Operation.

Reviewed By: rriddle, ftynse

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

This might be a small improvement in readability, but the
real motivation is to make it easier to adapt the code to
deal with intrinsics like 'maxnum' and/or integer min/max.

There is potentially help in doing that with D92086, but
we might also just add specialized wrappers here to deal
with the expected patterns.

OpenMPIRBuilder::createParallel outlines the body region of the parallel
construct into a new function that accepts any value previously defined outside
the region as a function argument. This function is called back by OpenMP
runtime function __kmpc_fork_call, which expects trailing arguments to be
pointers. If the region uses a value that is not of a pointer type, e.g. a
struct, the produced code would be invalid. In such cases, make createParallel
emit IR that stores the value on stack and pass the pointer to the outlined
function instead. The outlined function then loads the value back and uses as
normal.

Reviewed By: jdoerfert, llitchev

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

When importing symbols from another module, also import any
corresponding symver directives.

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

This also removes the empty extra "module asm" that would be created,
and updates the test to reflect that while making it more explicit.

Broken out from https://reviews.llvm.org/D92335

Add vand, vor, and vxor intrinsic instructions and regression tests.

Reviewed By: simoll

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

This patch consists of the addition of some common additional
extended mnemonics to the SystemZ target.

- These are jnop, jct, jctg, jas, jasl, jxh, jxhg, jxle,
  jxleg, bru, brul, br*, br*l.
- These mnemonics and the instructions they map to are
  defined here, Chapter 4 - Branching with extended
  mnemonic codes.
- Except for jnop (which is a variant of brc 0, label), every
  other mnemonic is marked as a MnemonicAlias since there is
  already a "defined" instruction with the same encoding
  and/or condition mask values.
- brc 0, label doesn't have a defined extended mnemonic, thus
  jnop is defined using as an InstAlias. Furthermore, the
  applyMnemonicAliases function is called in the overridden
  parseInstruction function in SystemZAsmParser.cpp to ensure
  any mnemonic aliases are applied before any further
  processing on the instruction is done.

Reviewed By: uweigand

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

In this patch I have added support for a new loop hint called
vectorize.scalable.enable that says whether we should enable scalable
vectorization or not. If a user wants to instruct the compiler to
vectorize a loop with scalable vectors they can now do this as
follows:

  br i1 %exitcond, label %for.end, label %for.body, !llvm.loop !2
  ...
  !2 = !{!2, !3, !4}
  !3 = !{!"llvm.loop.vectorize.width", i32 8}
  !4 = !{!"llvm.loop.vectorize.scalable.enable", i1 true}

Setting the hint to false simply reverts the behaviour back to the
default, using fixed width vectors.

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

This patch moves all s390x tests in init.c and init-zos.c to init-s390x.c.

Reviewed By: muiez

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

Add libc strncpy implementation.

Reviewed By: sivachandra, gchatelet

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

The code that gets the ScriptInterpreter was not considering the
case that it receives a Lua interpreter.

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

This implementation of `ELFDumper<ELFT>::printAttributes()` in llvm-readobj has issues:
1) It crashes when the content of the attribute section is empty.
2) It uses `unwrapOrError` and `reportWarning` calls, though
   ideally we want to use `reportUniqueWarning`.
3) It contains a TODO about redundant format version check.

`lib/Support/ELFAttributeParser.cpp` uses a hardcoded constant instead of the named constant.

This patch fixes all these issues.

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

Reviewed By: sdesmalen

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

std::addressof was made constexpr in gcc 7.
libc++ fixed it in ac473034 (Provide a constexpr addressof with GCC 7.)

This doesn't seem to be needed for anything.

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

Our warnings/errors reported are using lowercase normally.

This addresses one of review comments from D92382.

This makes the warnings reported to be unique and adds test cases.

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

We currently reject all templates that have either zero args or that have a
parameter pack without a name. Both cases are actually allowed in C++, so
rejecting them leads to LLDB instead falling back to a dummy 'void' type. This
leads to all kind of errors later on (most notable, variables that have such
template types appear to be missing as we can't have 'void' variables and
inheriting from such a template type will cause Clang to hit some asserts when
finding that the base class is 'void').

This just removes the too strict tests and adds a few tests for this stuff (+
some combinations of these tests with preceding template parameters).

Things that I left for follow-up patches:
* All the possible interactions with template-template arguments which seem like a whole new source of possible bugs.
* Function templates which completely lack sanity checks.
* Variable templates are not implemented.
* Alias templates are not implemented too.
* The rather strange checks that just make sure that the separate list of
  template arg names and values always have the same length. I believe those
  ought to be asserts, but my current plan is to move both those things into a
  single list that can't end up in this inconsistent state.

Reviewed By: JDevlieghere, shafik

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

These were re-added by fbfb1c79 but
should not have been. This removes the old experimental versions of the
reduction intrinsics again, leaving the new non experimental ones.

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

In lowering of FLT_ROUNDS_, FPSCR content will be moved into FP register
and then GPR, and then truncated into word.

For subtargets without direct move support, it will store and then load.
The load address needs adjustment (+4) only on big-endian targets. This
patch fixes it on using generic opcodes on little-endian and subtargets
with direct-move.

Reviewed By: steven.zhang

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

This:
1) Changes `reportWarning` to `reportUniqueWarning` (no-op here).
2) Adds more context to the message.
3) Merges `broken-dynsym-link.test` into `dyn-symbols.test`, adds more testing.

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

Commit 6b1341eb fixed alignment for 128-bit FP types on PowerPC.
However, the quadword alignment adjustment shouldn't be applied to IBM
extended double (ppc_fp128 in IR) values.

Reviewed By: jsji

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

This reverts a side effect introduced in the code cleanup patch D43571:
LLD started to emit empty output sections that are explicitly assigned to a segment.

This patch fixes the issue by removing the !sec.phdrs.empty() special case from
isDiscardable. As compensation, we add an early phdrs propagation step (see the inline comment).
This is similar to one that we do in adjustSectionsAfterSorting.

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

Reviewed By: rriddle

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

Add codecvt*<char16_t, char8_t> and codecvt*<char32_t, char8_t>.
Deprecate codecvt<char(16|32)_t, char>.
Enable disabled tests.
Update _LIBCPP_STD_VER to use 20 for C++20. Add _LIBCPP_DEPRECATED_IN_CXX20 macro.

Reviewed By: ldionne, #libc, #libc_abi

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

This fixes linking code that uses some bits of the <random> header
on mingw targets.

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

Also, add notes about exporting ABI symbols.
Later, we can add notes about using git-clang-format before sending a patch for review.

Reviewed By: ldionne, #libc

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

The 'AlignAsBaseClass' part was a leftover form the align_as test that served as
the template for this test.

i1 is the native type for PowerPC if crbits is enabled. However, we need
to promote the i1 to i64 as we didn't have the pattern for i1.

Reviewed By: Qiu Chao Fang

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

Also, for .o files, include full path as given on link command line.

Before:
    lld: error: undefined symbol [...], referenced from sandbox_logging.o

After:
    lld: error: undefined symbol [...], referenced from libseatbelt.a(sandbox_logging.o)

Move archiveName up to InputFile so we can consistently use toString()
to print InputFiles in diags, and pass it to the ObjFile ctor. This
matches the ELF and COFF ports.

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

The definition was removed on Aug 7, 2018 in commit
640cb003, but the declaration has
remained since.

Reviewed By: samparker

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

This adds missing `select` instruction support and block return type
support for reference types. Also refactors WebAssemblyInstrRef.td and
rearranges tests in reference-types.s. Tests don't include `exnref`
types, because we currently don't support `exnref` for `ref.null` and
the type will be removed soon anyway.

Reviewed By: tlively, sbc100, wingo

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

The static_assert in "libcxx/include/memory" was the main offender here,
but then I figured I might as well `git grep -i instantat` and fix all
the instances I found. One was in user-facing HTML documentation;
the rest were in comments or tests.

I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:

- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
    This is the most common case.

- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
    Leaving these as `_VSTD::allocator` would also be fine, but I decided
    that removing the qualification is more consistent with existing practice.

- Names that specifically need un-versioned `std::` qualification,
    or that I wasn't sure about. For example, I didn't touch any code in
    <atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
    and I didn't touch any instances of `std::type_info`.

In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.

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