Fixes https://llvm.org/PR50157

Adds support for when the container being read from in a range-for is a member of a struct.

Reviewed By: aaron.ballman

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

This commit adds pooling_nchw_sum as a yaml op.

Reviewed By: cathyzhyi, gysit

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

isAbsent/isPresent helpers only give information about static presence
of intrinsic arguments. Many intrinsic arguments optionality is dynamic
(an absent dummy can legally be passed to these intrinsics). This
requires a different handling (like `handleDynamicOptional`).

Rename the helpers to avoid misleading coder/reader into thinking all
optionality cases are covered by them.

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

This patch aims to overcome an issue in these mappings where, when an ISD
node was registered with BEGIN_REGISTER_VP_SDNODE but outwidth the scope
of a pair of BEGIN_REGISTER_VP_INTRINSIC/END_REGISTER_VP_INTRINSIC
macros, the switch cases fell apart. This in particular happened with
VP_SETCC, where we'd end up with something along the lines of:

  case Intrinsic::vp_fcmp:
    break;
  case Intrinsic::vp_icmp:
    break;
    ResOpc = ISD::VP_SETCC;
  case Intrinsic::vp_store:
    ...

To remedy this, we introduce a special-purpose mapping macro which can
map any number of VP intrinsic opcodes to an ISD opcode.

As a result, we no longer need to special-case the mapping from vp.icmp
and vp.fcmp to VP_SETCC, as the new helper macro does it for us.

Thanks to @craig.topper for noticing this and to @rogfer01 for the idea.

Reviewed By: rogfer01

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

Perfect shuffle costs are always encoded less than 4, and shouldn't
really have a cost more than 3, so it makes no sense to check it when
generating shuffles. The perfect shuffle is likely always better than a
tbl too (although that may depend on whether it is in a loop).

Align guards of these builtins with opencl-c.h.

GCC 9 has problems with this.

mlir/include/mlir/IR/OperationSupport.h: In member function ‘mlir::Value mlir::MutableOperandRange::operator[](unsigned int) const’:
mlir/include/mlir/IR/OperationSupport.h:912:43: error: call of overloaded ‘OperandRange(const mlir::MutableOperandRange&)’ is ambiguous
  912 |     return static_cast<OperandRange>(*this)[index];
      |
mlir/include/mlir/IR/OperationSupport.h:789:21: note: candidate: mlir::OperandRange::OperandRange(const llvm::iterator_range<llvm::detail::indexed_accessor_
range_base<mlir::OperandRange, mlir::OpOperand*, mlir::Value, mlir::Value, mlir::Value>::iterator>&)
   using RangeBaseT::RangeBaseT;
                     ^~~~~~~~~~
mlir/include/mlir/IR/OperationSupport.h:786:7: note: candidate: constexpr mlir::OperandRange::OperandRange(const mlir::OperandRange&)
 class OperandRange final : public llvm::detail::indexed_accessor_range_base<
       ^~~~~~~~~~~~
mlir/include/mlir/IR/OperationSupport.h:786:7: note: candidate: constexpr mlir::OperandRange::OperandRange(mlir::OperandRange&&)

We found that it might be beneficial to have the SIOptimizeExecMasking
pass detect more cases where v_cmp, s_and_saveexec patterns can be
transformed to s_mov, v_cmpx patterns. Currently, the search range
for finding a fitting v_cmp instruction is 5, however, this is doubled
to 10 here.

Reviewed By: foad

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

`__is_callable` is required to ensure that the classic algorithms are only called with functions or functors. I also begin to granularize `<type_traits>`.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

Reviewed By: ldionne, var-const, #libc, nilayvaish

Spies: nilayvaish, libcxx-commits

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

Insert a buffer copy unless the dims are guaranteed to be collapsible. In the verifier, accept collapses unless they are guaranteed to be non-collapsible.

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

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

Insert a cast if the two tensors with identical layout (that are passed to `arith.select`) have different layout maps after bufferization.

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

Adjust the PMULLD entry to match the Intel AoM numbers - PMULLD is a uop nightmare on SLM and we should model it as such.

We had reports of internal regressions the last time this was attempted (rG13a0f83a05ff), but no public repros, and tests I did last year when I had access to a SLM box failed to see anything. My hunch is that the more aggressive PMULLD -> PMADDWD folds we now perform might have helped. We can revisit this again if we ever receive an actual repro.

Fixes #36407

From this comment: https://reviews.llvm.org/D123014#3436522

This removes support for performing LTO using the legacy pass
manager in LLVMgold.so. Explicitly enabling the new pass manager
is retained as a no-op.

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

This reverts commit fc2d8326.

I recently evaluated ~150 of bug reports on open source projects relating to my
GSoC'19 project, which was about tracking control dependencies that were
relevant to a bug report.

Here is what I found: when the condition is a function call, the extra notes
were almost always unimportant, and often times intrusive:

void f(int *x) {
  x = nullptr;
  if (alwaysTrue()) // We don't need a whole lot of explanation
                    // here, the function name is good enough.
    *x = 5;
}
It almost always boiled down to a few "Returning null pointer, which participates
in a condition later", or similar notes. I struggled to find a single case
where the notes revealed anything interesting or some previously hidden
correlation, which is kind of the point of condition tracking.

This patch checks whether the condition is a function call, and if so, bails
out.

The argument against the patch is the popular feedback we hear from some of our
users, namely that they can never have too much information. I was specifically
fishing for examples that display best that my contribution did more good than
harm, so admittedly I set the bar high, and one can argue that there can be
non-trivial trickery inside functions, and function names may not be that
descriptive.

My argument for the patch is all those reports that got longer without any
notable improvement in the report intelligibility. I think the few exceptional
cases where this patch would remove notable information are an acceptable
sacrifice in favor of more reports being leaner.

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

This test requires the X86 target to be available.

Make it clearer that this is a required dependency.

This adjusts the handling for:

export module  M;

export namespace {};

export namespace N {};
export using namespace N;

In the first case, we were allowing empty anonymous namespaces
as part of an extension allowing empty top-level entities, but that seems
inappropriate in this case, since the linkage would be internal for the
anonymous namespace.  We now report an error for this.

The second case was producing a warning diagnostic that this was
accepted as an extension - however the C++20 standard does allow this
as well-formed.

In the third case we keep the current practice that this is accepted with a
warning (as an extension). The C++20 standard says it's an error.

We also ensure that using decls are only applied to items with external linkage.

This adjusts error messages for exports involving redeclarations in modules to
be more specific about the reason that the decl has been rejected.

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

This revision supports to fold vector.extractelement (splat X) -> X.

Reviewed By: ftynse

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

This makes MemorySSA in LoopSink required, and removes the AST-based
implementation, as well as the related support code in LICM.

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

Rather than rewriting the alloca pointer to zero, use
removePointerBase() to drop the base pointer. This will simply bail
if the base pointer is not the alloca. We could try doing something
more fancy here (like dropping the sources not based on the alloca
on the premise that they aren't SafeStack-relevant), but I don't
think that's worthwhile.

Fixes https://github.com/llvm/llvm-project/issues/54784.

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

Reviewed By: ftynse

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

When an inline builtin declaration is shadowed by an actual declaration, we must
reference the actual declaration, even if it's not the last, following GCC
behavior.

This fixes #54715

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

It actually implements support for seeing through loads, using alias analysis to
refine the result.

This is rather limited, but I didn't want to rely on more than available
analysis at that point (to be gentle with compilation time), and it does seem to
catch common scenario, as showcased by the included tests.

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

The dependency scanner can reuse single FileManager instance across multiple translation units. This may lead to non-deterministic output depending on which TU gets processed first.

One of the problems is that Clang uses DirectoryEntry::getName in the header search algorithm. This function returns the path that was first used to construct the (shared) entry in FileManager. Using DirectoryEntryRef::getName instead preserves the case as it was spelled out for the current "get directory entry" request.

rdar://90647508

Reviewed By: dexonsmith

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

Reland Note: We've resolve the circular dependency issue on llvm/lib/Support and
llvm/TableGen.

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

RFC: https://discourse.llvm.org/t/rfc-increasing-the-gcc-and-clang-requirements-to-support-c-17-in-llvm

Following the policy here: https://llvm.org/docs/DeveloperPolicy.html#toolchain

This forum post here will be updated with the timeline and status: https://discourse.llvm.org/t/important-new-toolchain-requirements-to-build-llvm-will-most-likely-be-landing-within-a-week-prepare-your-buildbots/61447

Reviewed By: mehdi_amini, jyknight, jhenderson, cor3ntin, MaskRay

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

We are introducing branchless variants for sort3, sort4 and sort5.
These sorting functions have been generated using Reinforcement
Learning and aim to replace __sort3, __sort4 and __sort5 variants
for integral types.

The libc++ benchmarks were run on isolated machines for Skylake, ARM and
AMD architectures and achieve statistically significant improvement in
sorting random integers on test cases from sort1 to sort262144 for
uint32 and uint64.

A full performance overview for Intel Skylake, AMD and Arm can be
found here: https://bit.ly/3AtesYf

Reviewed By: ldionne, #libc, philnik

Spies: daniel.mankowitz, mgrang, Quuxplusone, andreamichi, philnik, libcxx-commits, nilayvaish, kristof.beyls

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

According to the RFC [0], this review contains the compiler-rt parts of large integer divison for _BitInt.

It adds the functions
```
/// Computes the unsigned division of a / b for two large integers
/// composed of n significant words.
/// Writes the quotient to quo and the remainder to rem.
///
/// \param quo The quotient represented by n words. Must be non-null.
/// \param rem The remainder represented by n words. Must be non-null.
/// \param a The dividend represented by n + 1 words. Must be non-null.
/// \param b The divisor represented by n words. Must be non-null.

/// \note The word order is in host endianness.
/// \note Might modify a and b.
/// \note The storage of 'a' needs to hold n + 1 elements because some
///       implementations need extra scratch space in the most significant word.
///       The value of that word is ignored.
COMPILER_RT_ABI void __udivmodei5(su_int *quo, su_int *rem, su_int *a,
                                  su_int *b, unsigned int n);

/// Computes the signed division of a / b.
/// See __udivmodei5 for details.
COMPILER_RT_ABI void __divmodei5(su_int *quo, su_int *rem, su_int *a, su_int *b,
                                 unsigned int words);
```
into builtins.
In addition it introduces a new "bitint" library containing only those new functions,
which is meant as a way to provide those when using libgcc as runtime.

[0] https://discourse.llvm.org/t/rfc-add-support-for-division-of-large-bitint-builtins-selectiondag-globalisel-clang/60329

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