X86: balance the frame prologue and epilogue on Win64

This was broken in ba1509da7b89c850c89f0f98afbab375794cd3c8.  The Win64
frame would not perform the setup of the Swift async context parameter
but would tear down the setup in the epilogue resulting in crashes.
This ensures that we do the full setup when we do the tear down.
Although this is non-conforming to the Win64 calling convention, it
corrects the setup and exposes the actual issue that the change
introduced: incorrect frame setup.

Reviewed By: rnk

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

[FuncSpec] Use std::pow instead of operator^

The original implementation calculating UserBonus uses operator ^, which means XOR in C++
language.
At the first glance of reviewing, I thought it should be power, my bad.
It doesn't make sense to use XOR here. So I believe it should be a
carelessness as I made.

Test Plan: check-all

Reviewed By: SjoerdMeijer

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

[NFC][sanitizer] Remove calls to __asan_get_current_fake_stack

Unnecessary with -fsanitize-address-use-after-return=never.

for issue: https://github.com/google/sanitizers/issues/1394

Reviewed By: vitalybuka

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

[DFSan] Handle landingpad inst explicitly as zero shadow.

Before this change, DFSan was relying fallback cases when getting origin
address.

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

[libc++] Promote GCC 11 to mandatory CI

Also, fix the last issue that prevented GCC 11 from passing the test
suite. Thanks to everyone else who fixed issues.

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

Don't depend on the "run" alias doing shell expanding.
Instead dial it up explicitly.

This test started failing recently and I'm not sure why.  It also
doesn't make sense to me the replacing "run" with "process launch -X 1 --"
should make any difference - run is an alias for the latter.  But
it does pass with the change, and unless we are testing for the exact
run alias, it's better to ask for what we want explicitly.

CMake: allow overriding CMAKE_CXX_VISIBILITY_PRESET

This allows overriding the `CMAKE_CXX_VISIBILITY_PRESET` on the command line. For example, setting the value to `default` lets PIC LLVM static libraries be converted to DSOs, without the need to rebuild LLVM with BUILD_SHARED_LIBS=ON.

Reviewed By: wenlei

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

[mlir][sparse] integration test for all-dense annotated "sparse" output

Reviewed By: gussmith23

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

Missed a Windows use of ValidForThisThread in the changes for
cfb96d845a684a5c567823dbe2aa4392937ee979.

[docs] Exclude FlangOption and re-generate ClangCommandLineReference.rst

[mlir][SCF] Remove empty else blocks of `scf.if` operations.

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

[OpaquePtr] Verify Opaque pointer in function parameter

Verifying opaque pointer as function parameter when using with `byval`, `byref`,
`inalloca`, `preallocated`.

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

[mlir][sparse] allow all-dense annotated "sparse" tensor output

This is a very careful start with alllowing sparse tensors at the
left-hand-side of tensor index expressions (viz. sparse output).
Note that there is a subtle difference between non-annotated tensors
(dense, remain n-dim, handled by classic bufferization) and all-dense
annotated "sparse" tensors (linearized to 1-dim without overhead
storage, bufferized by sparse compiler, backed by runtime support library).
This revision gently introduces some new IR to facilitate annotated outputs,
to be generalized to truly sparse tensors in the future.

Reviewed By: gussmith23, bixia

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

[SampleFDO] Using common linkage for the discriminator flag variable

We create flag variable "__llvm_fs_discriminator__" in the binary
to indicate that FSAFDO hierarchical discriminators are used.

This variable might be GC'ed by the linker since it is not explicitly
reference. I initially added the var to the use list in pass
MIRFSDiscriminator but it did not work. It turned out the used global
list is collected in lowering (before MIR pass) and then emitted in
the end of pass pipeline.

In this patch, we use a "common" linkage for this variable so that
it will be GC'ed by the linker.

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

Convert functions that were returning BreakpointOption * to BreakpointOption &.

This is an NFC cleanup.

Many of the API's that returned BreakpointOptions always returned valid ones.
Internally the BreakpointLocations usually have null BreakpointOptions, since they
use their owner's options until an option is set specifically on the location.
So the original code used pointers & unique_ptr everywhere for consistency.
But that made the code hard to reason about from the outside.

This patch changes the code so that everywhere an API is guaranteed to
return a non-null BreakpointOption, it returns it as a reference to make
that clear.

It also changes the Breakpoint to hold a BreakpointOption
member where it previously had a UP.  Since we were always filling the UP
in the Breakpoint constructor, having the UP wasn't helping anything.

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

[OpenMP] Add GOMP 5.0 version symbols to API

* Add GOMP versioned pause functions
* Add GOMP versioned affinity format functions

To do the affinity format functions, only attach versioned symbols
to the APPEND Fortran entries (e.g., omp_set_affinity_format_) since
GOMP only exports two symbols (one for Fortran, one for C). Our
affinity format functions have three symbols.
e.g., with omp_set_affinity_format:
1) omp_set_affinity_format (Fortran interface)
2) omp_set_affinity_format_ (Fortran interface)
3) ompc_set_affinity_format (C interface)

Have the GOMP version of the C symbol alias the ompc_* 3) version
instead of the Fortran unappended version 1).

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

[OpenMP] Fix affinity determine capable algorithm on Linux

Remove strange checks for syscall() arguments where mask is NULL.
Valgrind reports these as error usages for the syscall.
Instead, just check if CACHE_LINE bytes is long enough. If not, then
search for the size. Also, by limiting the first size detection
attempt to CACHE_LINE bytes, instead of 1MB, we don't use more than one
cache line for the mask size. Before this patch, sometimes the returned
mask size was 640 bytes (10 cache lines) because the initial call to
getaffinity() was limited only by the internal kernel mask size
which can be very large.

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

[OpenMP] Lazily assign root affinity

Lazily set affinity for root threads. Previously, the root thread
executing middle initialization would attempt to assign affinity
to other existing root threads. This was not working properly as the
set_system_affinity() function wasn't setting the affinity for the
target thread. Instead, the middle init thread was resetting the
its own affinity using the target thread's affinity mask.

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

AArch64 Linux and elf-core PAC stack unwinder support

This patch builds on D100521 and other related patches to add support
for unwinding stack on AArch64 systems with pointer authentication
feature enabled.

We override FixCodeAddress and FixDataAddress function in ABISysV_arm64
class. We now try to calculate and set code and data masks after reading
data_mask and code_mask registers exposed by AArch64 targets running Linux.

This patch utilizes core file linux-aarch64-pac.core for testing that
LLDB can successfully unwind stack frames in the presence of signed
return address after masking off ignored bits.

This patch also includes a AArch64 Linux native test case to demonstrate
successful back trace calculation in presence of pointer authentication
feature.

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

[libc][NFC] Disable thrd_test as it is exhibiting flaky behavior on the bots.

Revert "[MCA] Adding the CustomBehaviour class to llvm-mca"

This reverts commit f7a23ecece524564a0c3e09787142cc6061027bb.

It appears to breaks buildbots that don't build the AMDGPU backend.

[MCA] Adding the CustomBehaviour class to llvm-mca

Some instructions are not defined well enough within the target’s scheduling
model for llvm-mca to be able to properly simulate its behaviour. The ideal
solution to this situation is to modify the scheduling model, but that’s not
always a viable strategy. Maybe other parts of the backend depend on that
instruction being modelled the way that it is. Or maybe the instruction is quite
complex and it’s difficult to fully capture its behaviour with tablegen. The
CustomBehaviour class (which I will refer to as CB frequently) is designed to
provide intuitive scaffolding for developers to implement the correct modelling
for these instructions.

Implementation details:

llvm-mca does its best to extract relevant register, resource, and memory
information from every MCInst when lowering them to an mca::Instruction. It then
uses this information to detect dependencies and simulate stalls within the
pipeline. For some instructions, the information that gets captured within the
mca::Instruction is not enough for mca to simulate them properly. In these
cases, there are two main possibilities:

1. The instruction has a dependency that isn’t detected by mca.
2. mca is incorrectly enforcing a dependency that shouldn’t exist.

For the rest of this discussion, I will be focusing on (1), but I have put some
thought into (2) and I may revisit it in the future.

So we have an instruction that has dependencies that aren’t picked up by mca.
The basic idea for both pipelines in mca is that when an instruction wants to be
dispatched, we first check for register hazards and then we check for resource
hazards. This is where CB is injected. If no register or resource hazards have
been detected, we make a call to CustomBehaviour::checkCustomHazard() to give
the target specific CB the chance to detect and enforce any custom dependencies.

The return value for checkCustomHazaard() is an unsigned int representing the
(minimum) number of cycles that the instruction needs to stall for. It’s fine to
underestimate this value because when StallCycles gets down to 0, we’ll end up
checking for all the hazards again before the instruction is actually
dispatched. However, it’s important not to overestimate the value and the more
accurate your estimate is, the more efficient mca’s execution can be.

In general, for checkCustomHazard() to be able to detect these custom
dependencies, it needs information about the current instruction and also all of
the instructions that are still executing within the pipeline. The mca pipeline
uses mca::Instruction rather than MCInst and the current information encoded
within each mca::Instruction isn’t sufficient for my use cases. I had to add a
few extra attributes to the mca::Instruction class and have them get set by the
MCInst during instruction building. For example, the current mca::Instruction
doesn’t know its opcode, and it also doesn’t know anything about its immediate
operands (both of which I had to add to the class).

With information about the current instruction, a list of all currently
executing instructions, and some target specific objects (MCSubtargetInfo and
MCInstrInfo which the base CB class has references to), developers should be
able to detect and enforce most custom dependencies within checkCustomHazard. If
you need more information than is present in the mca::Instruction, feel free to
add attributes to that class and have them set during the lowering sequence from
MCInst.

Fortunately, in the in-order pipeline, it’s very convenient for us to pass these
arguments to checkCustomHazard. The hazard checking is taken care of within
InOrderIssueStage::canExecute(). This function takes a const InstRef as a
parameter (representing the instruction that currently wants to be dispatched)
and the InOrderIssueStage class maintains a SmallVector<InstRef, 4> which holds
all of the currently executing instructions. For the out-of-order pipeline, it’s
a bit trickier to get the list of executing instructions and this is why I have
held off on implementing it myself. This is the main topic I will bring up when
I eventually make a post to discuss and ask for feedback.

CB is a base class where targets implement their own derived classes. If a
target specific CB does not exist (or we pass in the -disable-cb flag), the base
class is used. This base class trivially returns 0 from its checkCustomHazard()
implementation (meaning that the current instruction needs to stall for 0 cycles
aka no hazard is detected). For this reason, targets or users who choose not to
use CB shouldn’t see any negative impacts to accuracy or performance (in
comparison to pre-patch llvm-mca).

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

Adding the rest of the C11 papers to the status page.

[gn build] Port 6478ef61b1a4

[InstSimplify] Treat invariant group insts as bitcasts for load operands

We can look through invariant group intrinsics for the purposes of
simplifying the result of a load.

Since intrinsics can't be constants, but we also don't want to
completely rewrite load constant folding, we convert the load operand to
a constant. For GEPs and bitcasts we just treat them as constants. For
invariant group intrinsics, we treat them as a bitcast.

Relanding with a check for self-referential values.

Reviewed By: lebedev.ri

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

[asan] Remove Asan, Ubsan support of RTEMS and Myriad

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

[NFC] Fix "unused variable" warning

Support lowering of index-cast on vector types.

The index cast operation accepts vector types. Implement its lowering in this patch.

Reviewed By: ftynse

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

Remove redundant test that was causing intermittent build bot failures.

Patch by Fred Grim!

Reviewed By: MyDeveloperDay

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

[NFC] Update renamed option in comments

c98ebda325c996b3a12f4fded0368734dc0fe28a Rename fp-op fusion option (yet
again) for compatibility with GCC option.

The comment in the header should be updated too to avoid confusion.

[libcxx][iwyu] ensures we IWYU as prep for modules

This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.

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

[PowerPC] Moving defineXLCompatMacros() definition

Moving the definition of the defineXLCompatMacros function from
the header file clang/lib/Basic/Targets/PPC.h to the source file
clang/lib/Basic/Targets/PPC.cpp.

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

[PowerPC] Fix spilling of paired VSX registers

We have added STXVP/LXVP for spilling and restoring the registers
but we neglected to add FI elimination code for these. The result
is that we end up producing impossible MachineInstr's that have
register operands in place of immediates.

[libc++] [P0619] Add _LIBCPP_ABI_NO_BINDER_BASES and remove binder typedefs in C++20.

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

Support: Remove F_{None,Text,Append} compatibility synonyms, NFC

Remove the compatibility spellings of `OF_{None,Text,Append}` that
were left behind by 1f67a3cba9b09636c56e2109d8a35ae96dc15782.

No functionality change here, just an API cleanup.

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

[X86] avoid assert with varargs, soft float, and no-implicit-float

Fixes:
 - PR36507 Floating point varargs are not handled correctly with
   -mno-implicit-float
 - PR48528 __builtin_va_start assumes it can pass SSE registers
   when using -Xclang -msoft-float -Xclang -no-implicit-float

On x86_64, floating-point parameters are normally passed in XMM
registers. For va_start, we spill those to memory so va_arg can
find them. There is an interaction here with -msoft-float and
-no-implicit-float:

When -msoft-float is in effect, instead of passing floating-point
parameters in XMM registers, they are passed in general-purpose
registers.

When -no-implicit-float is in effect, it "disables implicit
floating-point instructions" (per the LangRef). The intended
effect is to not have the compiler generate floating-point code
unless explicit floating-point operations are present in the
source code, but what exactly counts as an explicit floating-point
operation is not specified. The existing behavior of LLVM here has
led to some surprises and PRs.

This change modifies the behavior as follows:

  | soft | no-implicit | old behavior    | new behavior    |
  |  no  |   no        | spill XMM regs  | spill XMM regs  |
  | yes  |   no        | don't spill XMM | don't spill XMM |
  |  no  |  yes        | don't spill XMM | spill XMM regs  |
  | yes  |  yes        | assert          | don't spill XMM |

In particular, this avoids the assert that happens when
-msoft-float and -no-implicit-float are both in effect. This
seems like a perfectly reasonable combination: If we don't want
to rely on hardware floating-point support, we want to both
avoid using float registers to pass parameters and avoid having
the compiler generate floating-point code that wasn't in the
original program. Instead of crashing the compiler, the new
behavior is to not synthesize floating-point code in this
case. This fixes PR48528.

The other interesting case is when -no-implicit-float is in
effect, but -msoft-float is not. In that case, any floating-point
parameters that are present will be in XMM registers, and so we
have to spill them to correctly handle those. This fixes
PR36507. The spill is conditional on %al indicating that
parameters are present in XMM registers, so no floating-point
code will be executed unless the function is called with
floating-point parameters.

Reviewed By: rnk

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

[AMDGPU] Fix lds superalign test. NFC.

[compiler-rt][hwasan] Add GetShadowOffset function

Similar to SHADOW_OFFSET on asan, we can use this for hwasan so platforms that
use a constant value for the start of shadow memory can just use the constant
rather than access a global.

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

[NewPM] Remove SpeculateAroundPHIs pass

Addition of this pass has been botched.
There is no particular reason why it had to be sold as an inseparable part
of new-pm transition. It was added when old-pm was still the default,
and very *very* few users were actually tracking new-pm,
so it's effects weren't measured.

Which means, some of the turnoil of the new-pm transition
are actually likely regressions due to this pass.

Likewise, there has been a number of post-commit feedback
(post new-pm switch), namely
* https://reviews.llvm.org/D37467#2787157 (regresses HW-loops)
* https://reviews.llvm.org/D37467#2787259 (should not be in middle-end, should run after LSR, not before)
* https://reviews.llvm.org/D95789 (an attempt to fix bad loop backedge metadata)
and in the half year past, the pass authors (google) still haven't found time to respond to any of that.

Hereby it is proposed to backout the pass from the pipeline,
until someone who cares about it can address the issues reported,
and properly start the process of adding a new pass into the pipeline,
with proper performance evaluation.

Furthermore, neither google nor facebook reports any perf changes
from this change, so i'm dropping the pass completely.
It can always be re-reverted should/if anyone want to pick it up again.

Reviewed By: aeubanks

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

[lldb] Make the ClassTemplateDecl merging logic in TypeSystemClang respect template parameters

DWARF doesn't describe templates itself but only actual template instantiations.
Because of that LLDB has to infer the parameters of the class template
declarations from the actual instantiations when creating the internal Clang AST
from debug info

Because there is no dedicated DIE for the class template, LLDB also creates the
`ClassTemplateDecl` implicitly when parsing a template instantiation. To avoid
creating one ClassTemplateDecls for every instantiation,
`TypeSystemClang::CreateClassTemplateDecl` will check if there is already a
`ClassTemplateDecl` in the requested `DeclContext` and will reuse a found
fitting declaration.

The logic that checks if a found class template fits to an instantiation is
currently just comparing the name of the template. So right now we map
`template<typename T> struct S;` to an instantiation with the values `S<1, 2,
3>` even though they clearly don't belong together.

This causes crashes later on when for example the Itanium mangler's
`TemplateArgManglingInfo::needExactType` method tries to find fitting the class
template parameter that fits to an instantiation value. In the example above it
will try to find the parameter for the value `2` but will just trigger a
boundary check when retrieving the parameter with index 1 from the class
template.

There are two ways we can end up with an instantiation that doesn't fit to a
class template with the same name:

1. We have two TUs with two templates that have the same name and internal
   linkage.
2. A forward declared template instantiation is emitted by GCC and Clang
   without an empty list of parameter values.

This patch makes the check for whether a class template declaration can be
reused more sophisticated by also comparing whether the parameter values can fit
to the found class template. If we can't find a fitting class template we
justcreate a second class template with the fitting parameters.

Fixes rdar://76592821

Reviewed By: kastiglione

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

Revert "[ARM] Extend narrow values to allow using truncating scatters"

This commit adds nodes that might not always be used, which the
expensive checks builder does not like. Reverting for now to think up a
better way of handling it.

[NFC][OpaquePtr] Avoid calling getPointerElementType()

Pointee types are going away soon.

For this, we mostly just care about store/load types, which are already
available without the pointee types. The other intrinsics always use
i8*.

Reviewed By: dblaikie

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

[NFC] Remove redundant variable

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

Remove unnecessary triple from test

PR27098(https://bugs.llvm.org/show_bug.cgi?id=27098) has been fixed so
the avoidance seems unnecessary.

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

[ARM] Extend narrow values to allow using truncating scatters

As a minor adjustment to the existing lowering of offset scatters, this
extends any smaller-than-legal vectors into full vectors using a zext,
so that the truncating scatters can be used. Due to the way MVE
legalizes the vectors this should be cheap in most situations, and will
prevent the vector from being scalarized.

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

DirectoryWatcher: close a possible window of race on Windows

The initial scan occurring before the watcher is ready allows a race
condition where a change occurs before the initial scan completes.
Ensure that we wait for the watcher to begin executing the initial scan.

Addresses some feedback from Adrian McCarthy in post-commit review.

[ARM] Use rq gather/scatters for smaller v4 vectors

A pointer will always fit into an i32, so a rq offset gather/scatter can
be used with v4i8 and v4i16 gathers, using a base of 0 and the Ptr as
the offsets. The rq gather can then correctly extend the type, allowing
us to use the gathers without falling back to scalarizing.

This patch rejigs tryCreateMaskedGatherOffset in the
MVEGatherScatterLowering pass to decompose the Ptr into Base:0 +
Offset:Ptr (with a scale of 1), if the Ptr could not be decomposed from
a GEP. v4i32 gathers will already use qi gathers, this extends that to
v4i8 and v4i16 gathers using the extending rq variants.

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

[IROutliner] Adding DebugInfo handling for IR Outlined Functions

This adds support for functions outlined by the IR Outliner to be
recognized by the debugger.  The expected behavior is that it will
skip over the instructions included in that section.  This is due to the
fact that we can not say which of the original locations the
instructions originated from.

These functions will show up in the call stack, but you cannot step
through them.

Reviewers: paquette, vsk, djtodoro

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

[mlir][linalg] Adapt yaml codegen to support scalar parameters.

The patch updates the C++ yaml code generation to support scalar operands as added in https://reviews.llvm.org/D104220.

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

Work around MSVC compiler intricacies.

[flang] [openmp] Add Fortran specific semantic check 4 for OpenMP Allocate directive.

This patch adds the 4th Fortran specific semantic check for the OpenMP
allocate directive: "If a list item has the SAVE attribute, is a common
block name, or is declared in the scope of a module, then only predefined
memory allocator parameters can be used in the allocator clause".

Code in this patch was based on code from https://reviews.llvm.org/D93549/new/.

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

Revert "[libc] Add a set of elementary operations"

This reverts commit 8387187c2ffe0bef0696edfffab00cd7d0ee3e6e.

[libcxx][atomic] Fix failure mapping in compare_exchange_{strong,weak}.

https://eel.is/c++draft/atomics.types.operations#23 says: ... the value of failure is order except that a value of `memory_order::acq_rel` shall be replaced by the value `memory_order::acquire` and a value of `memory_order::release` shall be replaced by the value `memory_order::relaxed`.

This failure mapping is only handled for `_LIBCPP_HAS_GCC_ATOMIC_IMP`. We are seeing bad code generation for `compare_exchange_strong(cmp, 1, std::memory_order_acq_rel)` when using libc++ in place of libstdc++: https://godbolt.org/z/v3onrrq4G.

This was caught by tsan tests after D99434, `[TSAN] Honor failure memory orders in AtomicCAS`, but appears to be an issue in non-tsan code.

Reviewed By: ldionne, dvyukov

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

[mlir] Avoid GCC naming conflict.

Rename AbstractType to AbstractTy to avoid a GCC naming conflict after https://reviews.llvm.org/D104234.

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

[libc] Add a set of elementary operations

Resubmission of D100646 now making sure that we handle cases were `__builtin_memcpy_inline` is not available.

Original commit message:
Each of these elementary operations can be assembled to support higher order constructs (Overlapping access, Loop, Aligned Loop).
The patch does not compile yet as it depends on other ones (D100571, D100631) but it allows to get the conversation started.

A self-contained version of this code is available at https://godbolt.org/z/e1x6xdaxM

[ARM] Rejig some of the MVE gather/scatter lowering pass. NFC

This adjusts some of how the gather/scatter lowering pass passes around
data and where certain gathers/scatters are created from. It should not
effect code generation on its own, but allows other patches to more
clearly reason about the code.

A number of extra test cases were also added for smaller gathers/
scatters that can be extended, and some of the test comments were
updated.

[llvm-exegesis] Fix X86LbrCounter destructor to correctly unmap memory and not double-close fd (PR50620)

As was reported on PR50620, the X86LbrCounter destructor was double-closing the filedescriptor and not unmapping the buffer.

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

[mlir] Add SignOp to complex dialect.

Also add a conversion pattern from Complex Dialect to Standard/Math Dialect.

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

[mlir] separable registration of attribute and type interfaces

It may be desirable to provide an interface implementation for an attribute or
a type without modifying the definition of said attribute or type. Notably,
this allows to implement interfaces for attributes and types outside of the
dialect that defines them and, in particular, provide interfaces for built-in
types. Provide the mechanism to do so.

Currently, separable registration requires the attribute or type to have been
registered with the context, i.e. for the dialect containing the attribute or
type to be loaded. This can be relaxed in the future using a mechanism similar
to delayed dialect interface registration.

See https://llvm.discourse.group/t/rfc-separable-attribute-type-interfaces/3637

Depends On D104233

Reviewed By: rriddle

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

[mlir][linalg][python] Adapt the OpDSL to use scalars.

The patch replaces the existing capture functionality by scalar operands that have been introduced by https://reviews.llvm.org/D104109. Scalar operands behave as tensor operands except for the fact that they are not indexed. As a result ScalarDefs can be accessed directly as no indexing expression is needed.

The patch only updates the OpDSL. The C++ side is updated by a follow up patch.

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

[libc++] [test] Fix some GCC 11 errors/warnings in these tests. NFCI.

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

[Matrix] Add tests for fast-math flags & matrix codegen.

This has already been implemented in be2277fbf233 which adds
pragma fp support. This patch just adds test coverage for
regular fast-math flags (PR46165).

[Polly][Isl] Replacing isl method `to_str()` with `stringFromIslObj()`. NFC.

This is part of an effort to reduce the differences between the custom C++ bindings used right now by polly in `lib/External/isl/include/isl/isl-noxceptions.h` and the official isl C++ interface.

Changes made:
 - Removing method `to_str()` from all the classes in the isl C++ bindings.
 - Overload method `stringFromIslObj()` so it accepts isl C++ objects.
 - To keep backward compatibility `stringFromIslObj()` now accepts a value that is returned if the isl C object is `null` or doesn't have a string representation (by default it's an empty string). In some cases it's better to have the string "null" instead of an empty string.
 - isl-noexceptions.h has been generated by this https://github.com/patacca/isl/commit/d33ec3a3bbaf971b254a853e6d8200ff9f5a1385

Reviewed By: Meinersbur

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

[gn build] Port 4eb9fe2e1a07

[OPENMP]Fix PR50699: capture locals in combine directrives for aligned clause.

Need to capture locals in aligned clauses for the combined directives to
be fix the crash in the codegen.

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

[LoopDeletion] Check for irreducible cycles when deleting loops.

Loops with irreducible cycles may loop infinitely. Those cannot be
removed, unless the loop/function is marked as mustprogress.

Also discussed in D103382.

Reviewed By: nikic

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

[ORC] Fix endianness in manual serialization to match WrapperFunctionUtils.

[ORC] Fix missing std::move.

[ORC] Fix narrowing-in-initializer-list warnings.

[ORC] Fix missing function in unit test.

[mlir] ODS: do not emit trailing const for static methods

The generated C++ would be invalid.

Reviewed By: rriddle

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

Clearly specify that these are partially implemented features

[ORC] Make WrapperFunctionResult's ValuePtr member non-const.

The const qualifier was a hangover from an earlier iteration that allowed
wrapper functions to return pointers to const memory. This feature has
been removed, so there's no reason for this to be const any more, and
removing it eliminates const-cast warnings.

[ORC] Port WrapperFunctionUtils and SimplePackedSerialization from ORC runtime.

Replace the existing WrapperFunctionResult type in
llvm/include/ExecutionEngine/Orc/Shared/TargetProcessControlTypes.h with a
version adapted from the ORC runtime's implementation.

Also introduce the SimplePackedSerialization scheme (also adapted from the ORC
runtime's implementation) for wrapper functions to avoid manual serialization
and deserialization for calls to runtime functions involving common types.

[mlir][MemRef] Make sure types match when folding dim(reshape)

Reshape can take integer types in addition to index, but dim always
returns index.

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

[mlir] Add NegOp to complex dialect.

Also add a lowering pattern from complex dialect to standard dialect.

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

ABI breaking changes fixes.

This commit mostly just replaces bad uses of `NDEBUG` with uses of
`LLVM_ENABLE_ABI_BREAKING_CHANGES` - the safe way to include ABI
breaking changes (normally extra struct elements in headers).

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

[lldb] Fix libstdc++ 11's std::unique_ptr affecting LLDB testsuite TestDataFormatterStdUniquePtr.py

libstdc++ since version 11 has a conditional compilation based on
[[no_unique_address]] availability whether one element is either
inherited or put there as a field with [[no_unique_address]].

The code comment is by teemperor.

Reviewed By: teemperor

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

[X86] Schedule-model second (mask) output of GATHER instruction

Much like `mulx`'s `WriteIMulH`, there are two outputs of
AVX2 GATHER instructions. This was changed back in rL160110,
but the sched model change wasn't present.

So right now, for sched models that are marked as complete
(`znver3` only now), codegen'ning `GATHER` results in a crash:
```
DefIdx 1 exceeds machine model writes for early-clobber renamable $ymm3, dead early-clobber renamable $ymm2 = VPGATHERDDYrm killed renamable $ymm3(tied-def 0), undef renamable $rax, 4, renamable $ymm0, 0, $noreg, killed renamable $ymm2(tied-def 1) :: (load 32, align 1)
```
https://godbolt.org/z/Ks7zW7WGh

I'm guessing we need to deal with this like we deal with `WriteIMulH`.

Reviewed By: RKSimon

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

[analyzer] Decouple NoteTag from its Factory

This allows us to create other types of tags that carry useful
bits of information alongside.

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

[MCA][InstrBuilder] Check for the presence of flag VariadicOpsAreDefs.

This patch fixes the logic that checks for variadic register definitions,

Before llvm-svn 348114 (commit 4cf35b4ab0b), it was not possible to explicitly
mark variadic operands as definitions. By default, variadic operands of an
MCInst were always assumed to be uses. A number of had-hoc checks were
introduced in the InstrBuilder to fix the processing of variadic register
operands of ARM ldm/stm variants.

This patch simply replaces those old (and buggy) checks with a much simpler (and
correct) check for MCID::Flag::VariadicOpsAreDefs.

Fix Windows builders after 244601f4720d9cda6e81ea1908f3ce905a4bcb0e

Apparently __builtin_abort() is not supported when targetting Windows.
This should fix the following builder errors:
clang_rt.builtins-x86_64.lib(int_util.c.obj) : error LNK2019: unresolved
external symbol __builtin_abort referenced in function __compilerrt_abort_impl

[analyzer] Simplify the process of producing notes for stores

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

[analyzer] Extract InlinedFunctionCallHandler

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

[analyzer] Extract InterestingLValueHandler

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

[analyzer] Extract ArrayIndexHandler

One interesting problem was discovered here.  When we do interrupt
Tracker's track flow, we want to interrupt only it and not all the
other flows recursively.

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

[analyzer] Extract NilReceiverHandler

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

[analyzer] Extract ControlDependencyHandler

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

[analyzer] Refactor StoreSiteFinder and extract DefaultStoreHandler

After this patch, custom StoreHandlers will also work as expected.

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

[clang-format] distinguish function type casts after 21c18d5a04316891110cecc2bf37ce51533decba

https://github.com/llvm/llvm-project/commit/21c18d5a04316891110cecc2bf37ce51533decba
improved the detection of multiplication in function call argument lists,
but unintentionally regressed the handling of function type casts (there
were no tests covering those).
This patch improves the detection of function type casts and adds a few tests.

Reviewed By: HazardyKnusperkeks

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

[mlir][linalg] Fold linalg.pad_tensor if src type == result type

Fold PadTensorOp to source if source type and result type have static shape and are equal.

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

[IR] Remove forward declaration of GraphTraits from Type.h

This has been unnecessary since r352353 removed GraphTraits
specializations for Type, except that a couple of other headers were
accidentally relying on this declaration.

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

[builtins] Allow compiling the builtins without libc headers

When compiled with -ffreestanding, we should not assume that headers
declaring functions such as abort() are available. While the compiler may
still emit calls to those functions [1], we should not require the headers
to build compiler-rt since that can result in a cyclic dependency graph:
The compiler-rt functions might be required to build libc.so, but the libc
headers such as stdlib.h might only be available once libc has been built.

[1] From https://gcc.gnu.org/onlinedocs/gcc/Standards.html:
GCC requires the freestanding environment provide memcpy, memmove,
memset and memcmp. Finally, if __builtin_trap is used, and the target
does not implement the trap pattern, then GCC emits a call to abort.

Reviewed By: phosek

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

Revert "[libc] Add a set of elementary operations"

This reverts commit 454d92ac3b3b13f5c8b3f57e03b2d93f0cf60738.

[libc] Add a set of elementary operations

Resubmission of D100646 now making sure that we handle cases were `__builtin_memcpy_inline` is not available.

Original commit message:
Each of these elementary operations can be assembled to support higher order constructs (Overlapping access, Loop, Aligned Loop).
The patch does not compile yet as it depends on other ones (D100571, D100631) but it allows to get the conversation started.

A self-contained version of this code is available at https://godbolt.org/z/e1x6xdaxM

Support buffers in LinalgFoldUnitExtentDims

This doesn't add any canonicalizations, but executes the same
simplification on bufferSemantic linalg.generic ops by using
linalg::ReshapeOp instead of linalg::TensorReshapeOp.

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

[gn build] Port d0a5d8611935

[Debug-Info][CodeView] Fix GUID string generation for MSVC generated objects.

This patch is to address https://bugs.llvm.org/show_bug.cgi?id=50459.
  YAML:455:28: error: GUID strings are 38 characters long

The valid format for a GUID is {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
where X is a hex digit (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F).
The length of the individual components must be: 8, 4, 4, 4, 12.

For some cases, the converted string generated by obj2yaml, does not
comply with those lengths. yaml2obj checks that the GUID string must
be 38 characters including the dashes and braces.

Reviewed By: amccarth

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

[ORC-RT] Fix void function handling in the WrapperFunction utility.

Handlers returning void previously caused compile errors. Fix that by
substituting SPSEmpty placeholder values.

Revert "[NFC] This is a test commit to check commit access."

This reverts commit b4d40e19def8c2e1a77ae30b5ac16751d1c461f7.