Disambiguate conversion cast for GCC

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&&)

[AMDGPU] Increase detection range for s_mov, v_cmpx transformation.

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

[libc++] Add __is_callable type trait and begin granularizing type_traits

`__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

[libc++] Add tests for std::string default constructor and destructor

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

Spies: nilayvaish, libcxx-commits

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

compiler-rt/lib/builtins/udivmodei5.c: Fix missing macro argument

[InstCombine] Add various other modulo-by-constant tests for Issue #22303

[mlir][tensor] Fix verifier and bufferization of collapse_shape

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

[mlir][bufferize] Do not insert useless casts for newly allocated buffers

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

[mlir][arith][bufferize] Fix tensors with different layouts after bufferization

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

[X86] Fix SLM scheduler model for PMULLD (PR37059)

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

[spirv] Make header self-contained. NFC.

[X86] Add additional test for PR54369 (NFC)

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

[gold] Remove support for legacy pass manager

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

Revert "Reland "[RISCV][NFC] Moving RVV intrinsic type related util to llvm/Support""

This reverts commit fc2d8326ae4d6e05c1aa2db7e7dbd8e759bf4d51.

[analyzer] Don't track function calls as control dependencies

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

[MemoryBuiltins] Remove unnecessary lambda capture (NFC)

[SafeStack] Move test to X86 directory

This test requires the X86 target to be available.

[LICM] Pass MemorySSAUpdater by referene (NFC)

Make it clearer that this is a required dependency.

[C++20][Modules] Adjust handling of exports of namespaces and using-decls.

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

[mlir][Vector] Fold extractelement splat.

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

Reviewed By: ftynse

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

[LoopSink] Require MemorySSA

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

[SafeStack] Don't create SCEV min between pointer and integer (PR54784)

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

[mlir][Arithmetic] Add constant folder for negf.

Reviewed By: ftynse

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

[Clang][Fortify] drop inline decls when redeclared

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

[builtin_object_size] Basic support for posix_memalign

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

[clang][deps] Ensure deterministic filename case

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 "[RISCV][NFC] Moving RVV intrinsic type related util to llvm/Support"

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

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

Bump minimum toolchain version

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

Introduce branchless sorting functions for sort3, sort4 and sort5.

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

compiler-rt: Add udivmodei5 to builtins and add bitint library

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

[mlir][NFC] Drop a few unnecessary includes from Pass.h

[CSKY] Correct the alignment of FPR register

The alignment of FPR64 and sFPR64 declared in RegisterClass should be 32 bit.

[mlir] Add support for operation-produced successor arguments in BranchOpInterface

This patch revamps the BranchOpInterface a bit and allows a proper implementation of what was previously `getMutableSuccessorOperands` for operations, which internally produce arguments to some of the block arguments. A motivating example for this would be an invoke op with a error handling path:
```
invoke %function(%0)
  label ^success ^error(%1 : i32)

^error(%e: !error, %arg0 : i32):
  ...
```
The advantages of this are that any users of `BranchOpInterface` can still argue over remaining block argument operands (such as `%1` in the example above), as well as make use of the modifying capabilities to add more operands, erase an operand etc.

The way this patch implements that functionality is via a new class called `SuccessorOperands`, which is now returned by `getSuccessorOperands`. It basically contains an `unsigned` denoting how many operator produced operands exist, as well as a `MutableOperandRange`, which are the usual forwarded operands we are used to. The produced operands are assumed to the first few block arguments, followed by the forwarded operands afterwards. The role of `SuccessorOperands` is to provide various utility functions to modify and query the successor arguments from a `BranchOpInterface`.

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

[asan] Always skip first object from dl_iterate_phdr

All platforms return the main executable as the first dl_phdr_info.
FreeBSD, NetBSD, Solaris, and Linux-musl place the executable name
in the dlpi_name field of this entry. It appears that only Linux-glibc
uses the empty string.

To make this work generically on all platforms, unconditionally
skip the first object (like is currently done for FreeBSD and NetBSD).
This fixes first DSO detection on Linux-musl. It also would likely
fix detection on Solaris/Illumos if it were to gain PIE support
(since dlpi_addr would not be NULL).

Additionally, only skip the Linux VDSO on linux.

Finally, use the empty string as the "seen first dl_phdr_info"
marker rather than (char *)-1. If there was no other object, we
would try to dereference it for a string comparison.

Reviewed By: MaskRay, vitalybuka

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

[llvm-profgen] Filter out invalid LBR ranges.

The profiler can sometimes give us a LBR trace that implicates bogus code ranges. For example,

    0xc5acb56/0xc66c6c0 0xc628195/0xf31fbb0 0xc611261/0xc628130 0xc5c1a21/0xc6111c0 0x1f7edfd3/0xc5c3a50 0xc5c154f/0x1f7edec0 0xe8eed07/0xc5c11e0

, note that the first two pairs are supposed to form a linear execution range, in this case, it is [0xf31fbb0, 0xc5acb56] , which doesn't make sense.

Such bogus ranges should be ruled out to avoid generating a bad profile. I'm fixing this for both CS and non-CS cases.

Reviewed By: wenlei

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

[CSKY] support select instruction in floating type

In FPUv3, there is fsel.32/64 instruction to select float/double type data.
In FPUv2, split block and use branch and move instruction to select float/double type data.

[demangler] Support C23 _BitInt type

Reviewed By: #libc_abi, aaron.ballman, urnathan

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

NFC: Silence unused function 'scaleAndAdd' in release build.

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

[RISCV][NFC] Add missing lit.local.cfg in test/CodeGen/MIR/RISCV/

[gn build] Port 690085c9b715

[libomptarget] Implement pointer lookup as 5.1 spec.

As described in 5.1 spec
2.21.7.2 Pointer Initialization for Device Data Environments

Reviewed By: RaviNarayanaswamy

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

[RISCV] Fixing stack offset for RVV object with vararg in stack.

We found LLVM generate wrong stack offset for RVV object when stack
having variable argument, that cause by we didn't count vaarg part during
calculate RVV stack objects.

Also update the stack layout diagram for including vaarg in the diagram.

Stack layout ref:
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/riscv/riscv.cc#L3941

Reviewed By: rogfer01

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

[RISCV] Pre-commit for fixing stack offset for RVV object

Reviewed By: rogfer01, frasercrmck

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

[RISCV] Store/restore RISCVMachineFunctionInfo into MIR YAML file

RISCVMachineFunctionInfo has some fields like VarArgsFrameIndex and
VarArgsSaveSize are calculated at ISel lowering stage, those info are
not contained in MIR files, that cause test cases rely on those field
can't not reproduce correctly by MIR dump files.

This patch adding the MIR read/write for those fields.

Reviewed By: frasercrmck

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

[NFC] Remove unused variable in CodeGenModules

This eliminates an unused-variable warning

Add support for atomic memory copy lowering

Currently, the utility supports lowering of non atomic memory transfer routines only. This patch adds support for atomic version of memcopy. This may be useful for targets not supporting atomic memcopy.

Reviewed By: arsenm

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

[mlir][LLVMIR] Add more vector predication intrinsic ops.

This revision adds float unary, ternary and float/integer reduction intrinsic ops.

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

[InferAddressSpaces] Fix assert on invalid bitcast placement

Similar to the problem in 0bb25b4603, bitcasts that are inserted must
dominate all uses. When rewriting "values" with "new values" that have
the updated address space, we may replace the "new value" with a bitcast
if one of the original users is an addresspace cast. This bitcast must
be inserted before ALL users, not only before the addresspace cast.

Reviewed By: arsenm

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

[RISCV][NFC] Use defvar to simplify pattern definations.

Reviewed By: frasercrmck

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

[InstCombine] fold more constant divisor to select-of-constants divisor

By adding a parameter to function FoldOpIntoSelect， we can fold more Ops to Select.
For this example, we tend to fold the division instruction,
so we no longer care whether SelectInst is one use.

This patch slove TODO left in InstCombine/div.ll.

Reviewed By: RKSimon

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

[mlir] Width parameterization of BitEnum attributes

This diff contains:

- Parameterization of bit enum attributes in OpBase.td by bit width (e.g. 32
and 64). Previously, all enums were 32-bits. This brings enum functionality in
line with other integer attributes, and allows for bit enums greater than 32
bits.
- SPIRV and Vector dialects were updated to use bit enum attributes with an
  explicit bit width

Reviewed By: mehdi_amini

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

NFC: Eliminate warning for unused type alias FnTraitsT in release builds.

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

[ORC] Fix handling of casts in llvm.global_ctors.

Removes a bogus dyn_cast_or_null that was breaking cast-expression handling when
parsing llvm.global_ctors.

The intent of this code was to identify Functions nested within cast
expressions, but the offending dyn_cast_or_null was actually blocking that:
Since a function is not a cast expression, we would set FuncC to null and break
the loop without finding the Function. The cast was not necessary either:
Functions are already Constants, and we didn't need to do anything
ConstantExpr-specific with FuncC, so we could just drop the cast.

Thanks to Jonas Hahnfeld for tracking this down.

http://llvm.org/PR54797

DebugInfo: Consider the type of NTTP when simplifying template names

Since the NTTP may need to be cast to the type when rebuilding the name,
check that the type can be rebuilt when determining whether a template
name can be simplified.

[MSAN] extend prctl interceptor to support PR_SCHED_CORE

Reviewed By: eugenis

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

[trace][intel pt] Create a common accessor for live and postmortem data

Some parts of the code have to distinguish between live and postmortem threads
to figure out how to get some data, e.g. thread trace buffers. This makes the
code less generic and more error prone. An example of that is that we have
two different decoders: LiveThreadDecoder and PostMortemThreadDecoder. They
exist because getting the trace bufer is different for each case.

The problem doesn't stop there. Soon we'll have even more kinds of data, like
the context switch trace, whose fetching will be different for live and post-
mortem processes.

As a way to fix this, I'm creating a common API for accessing thread data,
which is able to figure out how to handle the postmortem and live cases on
behalf of the caller. As a result of that, I was able to eliminate the two
decoders and unify them into a simpler one. Not only that, our TraceSave
functionality only worked for live threads, but now it can also work for
postmortem processes, which might be useful now, but it might in the future.

This common API is OnThreadBinaryDataRead. More information in the inline
documentation.

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

[trace][intel pt] Create a class for the libipt decoder wrapper

As we soon will need to decode multiple raw traces for the same thread,
having a class that encapsulates the decoding of a single raw trace is
a stepping stone that will make the coming features easier to implement.

So, I'm creating a LibiptDecoder class with that purpose. I refactored
the code and it's now much more readable. Besides that, more comments
were added. With this new structure, it's also easier to implement unit
tests.

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

[test][DSE] Precommit more assume tests

Fix format specifier. NFCI.

Using a portable format specifier avoids a "format specifies type
'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned
long') [-Werror,-Wformat]" error depending on the exact definition of
`uint64_t`.

[llvm-symbolizer] Fix line offset for inline site.

This fixes the issue when the current line offset is actually for next range.

Maintain a current code range with current line offset and cache next file/line
offset. Update file/line offset after finishing current range.

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

[lld-macho][nfc] Give non-text ConcatOutputSections order-independent finalization

This diff is motivated by my work to add proper DWARF unwind support. As
detailed in PR50956 functions that need DWARF unwind need to have
compact unwind entries synthesized for them. These CU entries encode an
offset within `__eh_frame` that points to the corresponding DWARF FDE.

In order to encode this offset during
`UnwindInfoSectionImpl::finalize()`, we need to first assign values to
`InputSection::outSecOff` for each `__eh_frame` subsection. But
`__eh_frame` is ordered after `__unwind_info` (according to ld64 at
least), which puts us in a bit of a bind: `outSecOff` gets assigned
during finalization, but `__eh_frame` is being finalized after
`__unwind_info`.

But it occurred to me that there's no real need for most
ConcatOutputSections to be finalized sequentially. It's only necessary
for text-containing ConcatOutputSections that may contain branch relocs
which may need thunks. ConcatOutputSections containing other types of
data can be finalized in any order.

This diff moves the finalization logic for non-text sections into a
separate `finalizeContents()` method. This method is called before
section address assignment & unwind info finalization takes place. In
theory we could call these `finalizeContents()` methods in parallel, but
in practice it seems to be faster to do it all on the main thread.

Reviewed By: #lld-macho, oontvoo

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

[AMDGPU] Fix handling of gfx10 LDS misaligned access bug

It was only handled for FLAT initially because we did not have
unaligned DS instructions lowering. Now it is implemented but
the bug is not handled.

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

[compiler-rt][builtins] Move DMB definition to syn-ops.h

Compiler-rt cross-compile for ARMv5 fails because D99282 made it an error if DMB
is used for any pre-ARMv6 targets. More specifically, the "#error only supported
on ARMv6+" added in D99282 will cause compilation to fail when any source file
which includes assembly.h are compiled for pre-ARMv6 targets. Since the only
place where DMB is used is syn-ops.h (which is only included by
arm/sync_fetch_and_* and these files are excluded from being built for older
targets), this patch moves the definition there to avoid the issues described
above.

Reviewed By: efriedma

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

Revert "[PowerPC] Fix EmitPPCBuiltinExpr to emit arguments once"

This reverts commit 2aae5b1fac3898afa10b550eee5e97f394aed0e6. Because it
breaks tests on windows.

[ELF] Fix non-relocatable-non-emit-relocs --gc-sections to discard .L symbols

This reverts commit 764cd491b126318add093c7c8ba3884967d64b21, which I
incorrectly assumed NFC partly because there were no test coverage for the
non-relocatable non-emit-relocs case before 9d6d936243fe343abe89323a27c7241b395af541.

The interaction of {,-r,--emit-relocs} {,--discard-locals} {,--gc-sections} is
complex but without -r/--emit-relocs, --gc-sections does need to discard .L
symbols like --no-gc-sections. The behavior matches GNU ld.

[AMDGPU] Split unaligned LDS access instead of scalarizing

There is no need to fully scalarize an unaligned operation in
some case, just split it to alignment.

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

[ELF][test] Improve discard-locals.s

[LV] Add test case for PR54427.

Reduced test for #54427.

[PowerPC] Fix EmitPPCBuiltinExpr to emit arguments once

This patch changes `EmitPPCBuiltinExpr` in `CGBuiltin.cpp` to remove
the loop at the beginning of the function that emits the arguments and
to delay emitting the arguments until inside the switch statement. These
changes will put `EmitPPCBuiltinExpr` in line with the strategy of the
target independent function `EmitBuiltinExpr`. Also, this patch
ensures that arguments are only emitted once.

Tests that included builtins affected by these changes have been
modified to match expected behaviour.

Reviewed By: #powerpc, nemanjai, amyk

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

[lldb] Use getMainExecutable in SBDebugger::PrintStackTraceOnError

Implement Pavel's suggestion to use llvm::sys::fs::getMainExecutable to
find the executable name for llvm::sys::PrintStackTraceOnErrorSignal.

Revert "[libc++][format] Use a helper constant."

This reverts commit 82427685ea3732665286d5b1c8a1424b1f96164e.

This seems to break the AIX-32 bit build.

[lldb][gui] remove the "expand" diamond for variables where expanding fails

If the variables view shows a variable that is a struct that has
MightHaveChildren(), the expand diamond is shown, but if trying to expand
it and it's not possible (e.g. incomplete type), remove the expand diamond
to visualize that it can't be in fact expanded. Otherwise it feels kinda
weird that a tree item cannot be expanded even though it "should".

I guess the MightHaveChildren() checking means that GetChildren() may
be expensive, so also do not call it for rows that are not expanded.

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

[lldb][gui] handle Ctrl+C to stop a running process

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

[ARM] Add missing return to ARMTTIImpl::isLoweredToCall.

I assume we meant to return the result of the call to
BaseT::isLoweredToCall(F).

This might not be a functional change in practice because it would
still hit the default case in the switch and call
BaseT::isLoweredToCall(F) at the end.

Reviewed By: efriedma

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

[lld/mac] Add some comments and asserts

I was wondering if SymtabSection::emitStabs() should check
defined->includeInSymtab. Add asserts and comments explaining why that's not
necessary.

No behavior change.

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

[Driver][NFC] Simplify handling of flags in Options.td

We aim at improving the readability and maintainability of Options.td,
and in particular its handling of 'Flags', by
 - limiting the extent of 'let Flags = [...] in {'s, and
 - adding closing comments to matching '}'s.
 - being more consistent about empty lines around 'let Flags' and '}'.

More concretely,
 - we do not let a 'let Flags' span across several headline comments.
   When all 'def's in two consecutive headlines share the same flags,
   we stil close and start a new 'let Flags' at the intermediate
   headline.
 - when a 'let Flags' span just one or two 'def's, set 'Flags' within
   the 'def's instead.
 - we remove nested 'let Flags'.

Note that nested 'let Flags' can be quite confusing, especially when
the outer was started long before the inner. Moving a 'def' out of the
inner 'let Flags' and setting 'Flags' within the 'def' will not have the
intended effect, as those flags will be overridden by the outer
'let Flags'.

Reviewed By: awarzynski, jansvoboda11, hans

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

Reland [GreedPatternRewriter] Preprocess constants while building worklist when not processing top down

Reland Note: Adds a fix to properly mark a commutative operation as folded if we change the order
             of its operands. This was uncovered by the fact that we no longer re-process constants.

This avoids accidentally reversing the order of constants during successive
application, e.g. when running the canonicalizer. This helps reduce the number
of iterations, and also avoids unnecessary changes to input IR.

Fixes #51892

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

[lld-macho][nfc] Remove indirection when looking up common section members

{D118797} means that we can now check the name/segname of a given
section directly, instead of having to look those properties up on one
of its subsections. This allows us to simplify our code.

Reviewed By: #lld-macho, oontvoo

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

[AArch64] Insert subvector costs

An insert subvector under aarch64 can often be done as a single lane mov
operation. For example a v4i8 inserted into a v16i8 is a s-reg mov, so
long as the index is a multiple of 4. This teaches the cost model that,
using code copied over from the X86 backend.

Some of the costs (v16i16_4_0) are still high because they get matched
as a SK_Select, not an SK_InsertSubvector. D120879 has some codegen
tests for inserting subvectors, which I were added as
llvm/test/CodeGen/AArch64/insert-subvector.ll.

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

[OpenMP] Add dynamic memory function to omp.h and add documentation

This patch adds the `llvm_omp_target_dynamic_shared_alloc` function to
the `omp.h` header file so users can access it by default. Also changed
the name to keep it consistent with the other target allocators. Added
some documentation so users know how to use it. Didn't add the interface
for Fortran since there's no way to test it right now.

Reviewed By: jdoerfert

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

[OpenMP] Change target memory tests to use allocators

The target allocators have been supported for NVPTX offloading for
awhile. The tests should use the allocators instead of calling the
functions manually. Also the comments indicating these being a preview
should be removed.

Reviewed By: jdoerfert

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

[mlir][ods] Fix builder gen for VariadicRegion with inferred types

Builders generated for ops with variadic regions and inferred return types were not being correctly generated (missing parameter).

[lldb] Add Python bindings to print stack traces on crashes.

As noticed in D87637, when LLDB crashes, we only print stack traces if
LLDB is directly executed, not when used via Python bindings. Enabling
this by default may be undesirable (libraries shouldn't be messing with
signal handlers), so make this an explicit opt-in.

I "commandeered" this patch from Jordan Rupprecht who put this up for
review originally.

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

[clang] Use -triple, not -target for %clang_cc1

[clang] Fix macos build broken after D120989

[clang-tidy] Fix invalid fix-it for cppcoreguidelines-prefer-member-initializer

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

Reviewed By: LegalizeAdulthood

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

[clang][extract-api][NFC] Use dedicated API to check for macro equality

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

[tosa][mlir] Add dynamic width/height support for depthwise convolution in tosa-to-linalg

In addition, fixed a small bug with padding incorrectly inferring output shape for dynaic inputs in convolution

Reviewed By: jpienaar

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

InstCombineCalls: fix annotateAnyAllocCallSite to report changes

Spotted during review of D123052.

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

[X86] Add PR35202 test case for commuted cmp merging

Test coverage for Issue #34550

[clang][NFC] Extract EmitAssemblyHelper::shouldEmitRegularLTOSummary

The code to check if the regular LTO summary should be emitted and to
add the corresponding module flags was duplicated in the
'EmitAssemblyHelper::EmitAssemblyWithLegacyPassManager' and
'EmitAssemblyHelper::RunOptimizationPipeline' methods.

In order to eliminate these code duplications, the
'EmitAssemblyHelper::shouldEmitRegularLTOSummary' method has been
extracted. The method returns a bool value, the value is 'true' if the
module summary should be emitted. The patch keeps the setting of the
module flags inline.

Reviewed By: tejohnson

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

[libc++][format] Use a helper constant.

The code accidentally uses a hard-coded value. Use a constant to make
sure the same value is used at both places.

[clang][ExtractAPI] Fix declaration fragments for ObjC methods

Objective-C methods selector parts should be considered as identifiers.

Depends on D123259

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

[CaptureTracking] Ignore ephemeral values when determining pointer escapeness

Ephemeral values cannot cause a pointer to escape.

No change in compile time:
https://llvm-compile-time-tracker.com/compare.php?from=4371710085ba1c376a094948b806ddd3b88319de&to=c5ddbcc4866f38026737762ee8d7b9b00395d4f4&stat=instructions

This partially fixes some regressions caused by more calls to `__builtin_assume` (D122397).

Reviewed By: asbirlea

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

[X86] Add PR19752 test case

Test coverage for Issue #20126

[AArch64] Update tests with the `update_llc_test_checks.py` script (NFC)

Reviewed By: Kmeakin

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

[mlir][vector] Fold extract(broadcast) of same rank

This case is handled in neither the folding or canonicalization
patterns. The folding pattern cannot generate new broadcast ops,
so it should be handled by the canonicalization pattern.

Reviewed By: ThomasRaoux

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

[clang][extract-api] Process only APIs declared in inputs

We should only process APIs declared in the command line inputs to avoid
drowning the ExtractAPI output with symbols the user doesn't care about.
This is achieved by keeping track of the provided input files and
checking that the associated Decl or Macro is declared in one of those files.

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

MemoryBuiltins: only claim an allocator family on builtin functions

This lines up with other parts of the codebase that only use special
knowledge about allocator functions if they're builtins.

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

BuildLibCalls: also set allocsize() attributes

This is part of being able to get rid of two more columns in
MemoryBuiltins.cpp's large table. We'll have two more changes before
we can finish the job.

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