[ConstraintElimination] Add test for debug printing.

[ConstraintElimination] Re-enable debug print when adding facts. (NFC)

Also add test coverage for important debug output.

[DAG] Introduce getSplat utility for common dispatch pattern [nfc]

We have a very common pattern of dispatching between BUILD_VECTOR and SPLAT_VECTOR creation repeated in many cases in code.  Common the pattern into a utility function.

[Concepts] Fix Concepts on generic lambda in a VarTemplateSpecDecl

As fallout of the Deferred Concept Instantiation patch (babdef27c5), we
got a number of reports of a regression, where we asserted when
instantiating a constraint on a generic lambda inside of a variable
template. See: https://github.com/llvm/llvm-project/issues/57958

The problem was that getTemplateInstantiationArgs function only walked
up declaration contexts, and missed that this is not necessarily the
case with a lambda (which can ALSO be in a separate context).

This patch refactors the getTemplateInstantiationArgs function in a way
that is hopefully more readable, and fixes the problem with the concepts
on a generic lambda.

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

[mlir][sparse] Implement sparse_tensor.select

The region within sparse_tensor.select is used as the runtime criteria
for whether to keep the existing value in the sparse tensor.

While the sparse element is provided to the comparison, indices may also
be used to decide on whether to keep the original value. This allows, for
example, to only keep the upper triangle of a matrix.

Reviewed by: aartbik

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

[mlir-cpu-runner] Support parsing operations other than 'builtin.module' as top-level

This adds a `--no-implicit-module` option, which disables the insertion
of a top-level `builtin.module` during parsing. The top-level op is
required to have the `SymbolTable` trait.

The majority of the change here is removing `ModuleOp` from interfaces.

Reviewed By: rriddle

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

[RISCV] Add missing VL arguments to the creation of RISCVISD::VMV_V_X_VL nodes.

VMV_V_X_VL nodes should always have a passthru, a splat, and a VL.
We were sometimes missing the VL.

This went unnoticed because these cases were all selected into the
following node to form a .vx or .vi instruction. The ComplexPattern
that does this, doesn't check the VL operand. I've added an assert
to the ComplexPattern to catch if the operand is missing.

@qcolombet spotted some of these in D134703.

[flang] Skip creating AggregateStores for common block associated aggregates

Previously, AggregateStores were created for aggregates associated with common
blocks. As a) AggregateStoreMap uses scope and offset information to search for
aggregate stores and b) variables related to common blocks have their
offsets set relative to the common block itself, if there were multiple
equivalences and at least one involved variables defined in a common block there
was an opportunity for the scope/offset pairs to match between distinct
aggregate stores. As a result, entries in AggregateStoreMap could collide,
resulting in incorrect stores being returned for a particular variable.

To prevent these collisions, skip creating AggregateStores for aggregates which
are associated with common blocks. This information was already unused as
aggregates associated with common blocks are handled by instantiateCommon.

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

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

Revert "foo"

This reverts commit 2138ef354a2a8be9f273804e1133a3b97a493f03.

Forgot to squash

Revert "[RISCV] Add missing VL arguments to the creation of RISCVISD::VMV_V_X_VL nodes."

This reverts commit 4c03c9f375f326a87065443d649c6568a4b7dd67.

Forgot to squash

[RISCV] Add missing VL arguments to the creation of RISCVISD::VMV_V_X_VL nodes.

VMV_V_X_VL nodes should always have a passthru, a splat, and a VL.
We were sometimes missing the VL.

This went unnoticed because these cases were all selected into the
following node to form a .vx or .vi instruction. The ComplexPattern
that does this, doesn't check the VL operand. I've added an assert
to the ComplexPattern to catch if the operand is missing.

@qcolombet spotted some of these in D134703.

foo

[mlir][NFC] Use TypeRange in buildWithEntryBlock

This better integrates with builder methods that use TypeRange,
i.e. the recommended thing, instead of ArrayRef<Type>.

[mlir] Rename FunctionOpInterface::getBody to getFunctionBody

This is much more explicit, and prevents annoying conflicts with op
specific accessors (which may have a different contract). This is similar
to the past rename of getType -> getFunctionType,

Fixes #58030

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

[mlir] Add unsigned version of index_cast

This is required to be able to cast integer type to a potential larger index using zero-extend cast.

There is a larger change under discussion to move index ops in a separate dialect: https://discourse.llvm.org/t/rfc-index-dialect/65540/
Based on timing of this work this patch can be included as part of this effort but as a short term solution we may want to add this op to arithmetic dialect for now in order to fill the gap.

Reviewed By: Mogball, stellaraccident

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

[IVDescriptors] Before moving an instruction in SinkAfter checking if it is target of other instructions

The attached test case can cause LLVM crash in buildVPlanWithVPRecipes because
invalid VPlan is generated.

  FIRST-ORDER-RECURRENCE-PHI ir<%792> = phi ir<%501>, ir<%806>
  CLONE ir<%804> = fdiv ir<1.000000e+00>, vp<%17>      // use of %17
  CLONE ir<%806> = load ir<%805>
  EMIT vp<%17> = first-order splice ir<%792> ir<%806>   // def of %17
  ...

There is a use before def error on %17.

When vectorizer generates a VPlan, it generates a "first-order splice"
instruction for a loop carried variable after its definition. All related PHI
users are changed to use this "first-order splice" result, and are moved after
it. The move is guided by a MapVector SinkAfter. And the content of SinkAfter is
filled by RecurrenceDescriptor::isFixedOrderRecurrence.

Let's look at the first PHI and related instructions

  %v792 = phi double [ %v806, %Loop ], [ %d1, %Entry ]
  %v802 = fdiv double %v794, %v792
  %v804 = fdiv double 1.000000e+00, %v792
  %v806 = load double, ptr %v805, align 8

%v806 is a loop carried variable, %v792 is related PHI instruction. Vectorizer
will generated a new "first-order splice" instruction for %v806, and it will be
used by %v802 and %v804. So %v802 and %v804 will be moved after %v806 and its
"first-order splice" instruction. So SinkAfter contains

   %v802   ->  %v806
   %v804   ->  %v802

It means %v802 should be moved after %v806 and %v804 will be moved after %v802.
Please pay attention that the order is important.

When isFixedOrderRecurrence processing PHI instruction %v794, related
instructions are

  %v793 = phi double [ %v813, %Loop ], [ %d1, %Entry ]
  %v794 = phi double [ %v793, %Loop ], [ %d2, %Entry ]
  %v802 = fdiv double %v794, %v792
  %v813 = load double, ptr %v812, align 8

This time its related loop carried variable is %v813, its user is %v802. So
%v802 should also be moved after %v813. But %v802 is already in SinkAfter,
because %v813 is later than %v806, so the original %v802 entry in SinkAfter is
deleted, a new %v802 entry is added. Now SinkAfter contains

  %v804   ->  %v802
  %v802   ->  %v813

With these data, %v802 can still be moved after all its operands, but %v804
can't be moved after %v806 and its "first-order splice" instruction. And causes
use before def error.

So when remove/re-insert an instruction I in SinkAfter, we should also
recursively remove instructions targeting I and re-insert them into SinkAfter.
But for simplicity I just bail out in this case.

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

[flang] Write semantics tests for the FORM TEAM statement.

Reviewed By: ktras

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

[mlir][memref] Extend multi-buffering transform

Extend multi-buffering to simplify the affine map created if any of its operands are constants. This avoids downstream problems where more complex affine.apply operations cannot be expanded.
Transfer attributes from the old allocation to the new allocation.

Reviewed By: ThomasRaoux

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

[lld/COFF] Ignore `/ASSEMBLYDEBUG[:NONE]` and `/EMITPOGOPHASEINFO`

Adds aforementioned link switches in lld-link and ignores them.

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

[mlir][sparse] Refactor the conversion of the tensor reshape operators.

Move genReshapeDstShape to codegen utils to support the rewriting of the tensor
reshape operators for the codegen path.

Reviewed By: aartbik

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

[libc++] Suppress -Wctad-maybe-unsupported on types w/o deduction guides

There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.

This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).

This is a re-application of the original patch by Eric Fiselier in
fcd549a7d828 which had been reverted due to reasons lost at this point.
I also added the macro to a few more types. Reviving this patch was
prompted by the discussion on https://llvm.org/D133425.

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

[DirectX] Add DXIL metadata `dx.shaderModel`

This captures the target shader model and pipeline stage into the DXIL
metadata for consumption by the DirectX runtime.

Reviewed By: python3kgae

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

[RISCV] Pass the destination register to getVLENFactoredAmount instead of returning it. NFC

This is a refactor for another patch. For now we move the vreg
creation to the caller.

Reviewed By: frasercrmck

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

[Driver] Remove unneeded RenderAsInput flag

RenderAsInput is for -Wa,/-Wl, style options which forward their values
as used by llvm::opt::Arg::renderAsInput. These short options don't use RenderAsInput.

[ConstraintElimination] Simplify logic for using inverse predicate (NFC)

Recent improvements to the code structure mean we don't need to reset
the condition's predicate in the IR and later restore it. Remove the
restorer logic.

[mlir][tosa] Swap the reshape at the end of the reduce op for an expand_shape in tosa-to-linalg

Reviewed By: rsuderman

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

[ConstraintElimination] Remove stray comment (NFC).

The comment doens't apply in the current context, remove it.

[mlir][sparse] sorted coo co-iteration check test

Reviewed By: Peiming

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

[GlobalISel] Combine `(x + y) - y -> x` and friends

This adds a combine that handles

```
(x + y) - y -> x
(x + y) - x -> y
x - (y + x) -> 0 - y
x - (x + z) -> 0 - z
```

On AArch64, we get added benefit for `0 - y` because it can be selected to a
`neg` instruction.

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

[ConstraintElimination] Remove unused StackEntry::IsNot field. (NFC)

The field is no unused and can be removed.

[mlir][sparse][taco] Avoid hard-coding DimLevelType values.

Reviewed By: aartbik

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

[llvm-libtool-darwin] Add support for -dependency_info

When using llvm-libtool-darwin as a drop in replacement for cctools
libtool, Xcode expects you to create a dependency info file. This file
is a very simple format describing the input files, the output files,
and the version of the tool. This logic is mirrored from that of
ld64.lld, which supports creating this file as well. Ideally we could
extract it, but I don't think we want to throw this into one of the
grab-bag libraries given how small the logic is.

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

[llvm-libtool-darwin] Parse and ignore -syslibroot

cctools libtool allows you to link dynamic libraries by passing through
a number of arguments to ld64. Because of this the default arguments
libtool receives in Xcode contains arguments that only matter in that
case. This change ignores this argument, at least until we ever support
that dynamic use case, so that you can use llvm-libtool-darwin as a
drop-in replacement in Xcode for cctools libtool. There are more
arguments we could ignore for this case, but we can probably add those
as the use case comes up.

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

[DAG] Use getSplatBuildVector in a couple more places [nfc]

[lldb] [gdb-remote] Move ReadPacketWithOutputSupport() to client

Move ReadPacketWithOutputSupport() from GDBRemoteCommunication
to GDBRemoteClientBase.  This function is client-specific and moving
it there simplifies followup patches that split communication into
separate thread.

Sponsored by: The FreeBSD Foundation

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

[mlir][c] Init MLProgram C API

Add MLIR upstream C api library definition.

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

[AArch64] Add support to loop vectorization for non temporal loads

Currently, AArch64 doesn't support vectorization for non temporal loads because `isLegalNTLoad` is not implemented for the target.
This patch applies similar functionality as `D73158` but for non temporal loads

Reviewed By: fhahn

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

[SimplifyLibCalls] Reduce code duplication. NFC

Reviewed By: nikic, nickdesaulniers, xbolva00

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

[Clang] Make offloading flags accept '-' and '--'

Currently all of the flags beginning with `--offload` such as
`--offload-arch` or `--offload-device-only` require the double-dash
form. However, if a user uses a single dash it will instead name a file
'ffload-arch' for example. This has been the cause of a lot of user
confusion. This patch changes these options to also accept a single
dash. This is similar to many other driver arguments beginning with
`-o`.

Reviewed By: JonChesterfield

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

[WebAssembly] Fix return type of __builtin_return_address under wasm64

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

[OpenMP][libomp] Allow unused-but-set warnings

Only a few remaining which are taken care of by this patch.

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

Revert "[InstSimplify] reduce code duplication for fmul folds; NFC"

This reverts commit 7b7940f9da80de6aa0b8f28a0ef809dafe4cdffc.
This missed a test update.

[ConstraintElimination] Add tests for chained GEPs with const offsets.

Add extra tests for chained GEPs where the second GEP has a constant
offset. Inspired by missed optimizations from #51358.

Fix compilation of CodeLayout.cpp for MacOS

llvm/lib/Transforms/Utils/CodeLayout.cpp uses std::abs() with double argument,
which is provided by cmath header, which is not explicitly included into CodeLayout.cpp.
The implicit include in llvm/include/llvm/Support/MathExtras.h was removed in
commit 16544cbe64b81a50800a88296ef37f4873a37b25

Inserting explicit include of cmath into CodeLayout.cpp in order to fix build on MacOS.

Committed on behalf of alsemenov (Aleksei Semenov)
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D135072

[InstSimplify] reduce code duplication for fmul folds; NFC

The constant is already commuted for an fmul opcode,
but this code can be called more directly for fma,
so we have to swap for that caller. There are tests
in InstSimplify and InstCombine to verify that this
works as expected.

[ARM][AArch64] Dont use macros for half instrinsics in NeonEmitter

We don't require arm_neon.h fp16 intrinsics to be treated as macros any
more.

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

[AArch64] Add pr58109 tests, one showing incorrect lowering of SUBS. NFC

Also added global-isel coverage for the same file.

[LoopVectorize] Add missing test for D133687

[mlir][shape] fix test added in 9f77909.

The stderr to stdout piping results in the two streams being interleaved on Windows.
Write stderr to a temp-file instead and run separate FileCheck on it.

[analyzer][NFC] Add tests for D132236

D132236 would have introduced regressions in the symbol lifetime
handling. However, the testsuite did not catch this, so here we have
some tests, which would have break if D132236 had landed.

This patch addresses the comment https://reviews.llvm.org/D132236#3753238

Co-authored-by: Balazs Benics <balazs.benics@sonarsource.com>
Reviewed By: martong

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

[OpenMP] Ignore schedule modifier in static scheduling

The modifier bits in the schedule type is not used/supported in the
static scheduler, so it should be ignored.

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

[ARM64EC][clang-cl] Add /arm64EC flag

Reviewed By: DavidSpickett

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

[lld/mac] Extract a reportUndefinedSymbol function

Makes things look more similar to the ELF port, and removes some
slightly deep nesting.

No behavior change.

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

[mlir] fix markdown headers in structured ops doc

[SelectionDAG] Fix use-after-free introduced in D130881

The code introduced in https://reviews.llvm.org/D130881 has a bug as it may cause a use-after-free error that can be caught by ASAN.
The bug essentially boils down to iterator invalidation of `DenseMap`. The expression `SDEI[To] = I->second;` may cause `SDEI` to grow if `To` is inserted for the very first time. When that happens, all existing iterators to the map are invalidated as their backing storage has been freed. Accessing `I->second` is then invalid and attempts to access freed memory (as `I` is an iterator of `SDEI`).

This patch fixes that quite simply by first making a copy of `I->second`, and then moving into the possibly newly inserted KV of the ` DenseMap`.

No test attached as I am not sure it is practible to test.

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

Revert "[CMake] Use libcxx-abi-* targets for in-tree sanitizer C++ ABI"

It casued some runtimes builds to fail with cmake error

  No target "libcxx-abi-static"

see code review.

> When in-tree libcxx is selected as the sanitizer C++ ABI, use
> libcxx-abi-* targets rather than libcxxabi and libunwind directly.
>
> Differential Revision: https://reviews.llvm.org/D134855

This reverts commit 414f9b7d2f45670019dc8ec284b685a9e238718f.

[libc++] Avoid relying on non-portable behaviour in std::align

Round-tripping pointers via size_t is not portable, the C/C++ standards
only require this to be valid when using (u)intptr_t.
Originally committed to the CHERI fork of LLVM as
https://github.com/CTSRD-CHERI/llvm-project/commit/dd01245185ab9e71b70b418bee8f11ea0199e1a3,
but I forgot to upstream the change. I rediscovered this issue due to a
compiler warning when building libc++ on a Arm Morello system.

Reviewed By: #libc, ldionne, philnik

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

[mlir][llvmir] Add filename debug info when converting from LLVMIR.

The revision enriches the debug locations generated during LLVMIR to MLIR translation with file name information and adds a separate test to exercise the debug location translation.

Reviewed By: ftynse

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

[flang] Add Sparc support to Optimizer/CodeGen/Target.cpp

As described in Issue #57642, `flang` currently lacks SPARC support in
`Optimizer/CodeGen/Target.cpp`, which causes a considerable number of tests
to `FAIL` with

  error: flang/lib/Optimizer/CodeGen/Target.cpp:310: not yet implemented:
target not implemented

This patch fixes this by following GCC`s documentation of the ABI described
in the Issue.

Tested on `sparcv9-sun-solaris2.11`.

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

[SelectionDAG] Add check for BUILD_VECTOR in isKnownNeverNaN

Includes handling of constants with vector type in isKnownNeverNaN.
For AMDGPU results in not making fcanonicalize during legalization
for vector inputs to fmaxnum_ieee and fminnum_ieee. Does not affect
end result since there is a combine that eliminates fcanonicalize.

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

[Analysis][SimplifyLibCalls] Refactor code related to size_t in lib func signatures. NFC

Added a helper in TargetLibraryInfo to get size of "size_t" in bits,
given a Module reference. The new getSizeTSize helper is using the
same strategy as for example isValidProtoForLibFunc has been using
in the past, assuming that the size can be derived by asking
DataLayout about the size/type of a pointer to int.

FortifiedLibCallSimplifier::optimizeStrpCpyChk was changed to use
the new getSizeTSize helper instead of assuming that sizeof(size_t)
is equal to sizeof(int*) by itself (that is the assumption used in
TargetLibraryInfoImpl::getSizeTSize so the result will be the same).

Having a common helper for this ensure that we use the same strategy
when deriving the size of "size_t" in different parts of the code.
One bonus with this refactoring (basing it on Module instead of just
DataLayout) is that it makes it easier to override this for a specific
target triple, in case the assumption of using getPointerSizeInBits
wouldn't hold.

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

[mlir][Affine] Add pass options to supervectorizer

The only current options to create a supervectorization pass from an
external dialect is to use `createSuperVectorizePass` with the virtual
vector dimensions as a parameter, but the pass accepts other parameters.

This patch enables external users to create a supervectorizer pass
exposing all available option.

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

[flang] Do not resolve TRIM/REPEAT length to its argument length

For TRIM and REPEAT calls, semantics was creating ProcedureDesignators
using the length parameter of the arguments. This caused bugs when
folding LEN(TRIM(char_explicit_constant_length)). The same did not
appeared in folding for REPEAT because it is rewritten at a higher
level to LEN(c)*N.

This is not only a folding issue since any place (like lowering) may
try to use the bad length parameter from the created ProcedureDesignator.

Update intrinsic resolution to not copy the length parameter for TRIM
and REPEAT.

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

[Test] Add test showing that Constraint Elimination can deal with case where SCEV fails

[DebugInfo][test] XFAIL DebugInfo/Generic/missing-abstract-variable.ll on LoongArch

The same as SPARC and RISCV. See D119122.

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

[flang][NFC] Use prefixed accessors for fircg dialect

The raw accessor is going away soon so switch to prefixed accessors in the
fircg dialect. The main dialect was switched some months ago.

https://github.com/llvm/llvm-project/issues/58090

Reviewed By: rriddle

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

[Clang][MinGW][cygwin] Fix __declspec with -fdeclspec enabled

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

Reviewed By: rnk

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

[LLD][COFF] Reduce chance of symbol name collision with delay-load

Delay-loaded imports creats a load thunk with a symbol name. Before this
change, the name uses a `__imp_load_` prefix. On the other hand, normal
import uses the `__imp_` prefix for the import address pointer. If an
import symbol named `load_func` is imported normally and another named
`func` is imported using delay-load, this can cause a symbol name
collision.

This patch changes delay-load imports to use `__imp___load_` prefix.
Because it is less likely for normal imports to have a name starting in
`__load_` this should reduce the chance of a name collision.

Reviewed By: mstorsjo

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

[LLD][COFF] Set OrdinalBase to 1 for export table

Before this, LLD sets OrdinalBase to 0, which deviates from usual
practices. This technically would allow LLD to export a symbol using
ordinal 0, however LLD never use export ordinal 0, which results in
binaries with export tables always having an empty export at ordinal 0.

This change makes LLD set OrdinalBase to 1 and not create the empty
export with ordinal 0, which makes its behaviour more in line with both
the MSVC linker and the GNU linker.

Reviewed By: mstorsjo

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

[libc++] Remove a part of reverted D131898 or D130695

Revert "[libc++] Updates generated transitve includes."

Looks like a part of reverted D131898.

This reverts commit cfd5b8f11195f5c23ae6d4aa2df2d95cae9b976e.

[flang] Make real type of kind 10 target dependent

The real(10) is supported on x86_64. On aarch64, the value of
selected_real_kind(16) should be 16 rather than 10 since real(10)
is not supported on x86_64. Previously, the real type support check
is not target dependent. Support it now through the target triple
information.

Reviewed By: clementval

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

[Bazel] fixes for 9f77909.

[mlir][bufferize][NFC] Fix FileCheck capture

One of the test cases matched IR from a subsequent test case. For this reason, the test case appeared to pass while it is actually broken.

This change does not fix the test case itself. It will be fixed when we overhaul the buffer deallocation implementation. (The memory leak in this test case is an edge case.)

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

[GlobalISel] Allow prelegalizer combiners to have access to LegalizerInfo.

Before, the isPreLegalize() query in CombinerHelper only checked for the
presence of a LegalizerInfo object. This is problematic when we want to have
a combine actually check for legality in a pre-legalizer combine pass, since
if we pass a LegalizerInfo object to the constructor it causes the combines to
think that we're running *post* legalizer, which isn't true.

This change fixes it to instead check an explicit bool that passes to signal
whether the pass will be run before or after legalization.

Doing so exposed a bug in the extending loads combine, which tried to check for
legality of candidate extending loads if LegalizerInfo was present. Since we
only ran it pre-legalizer and therefore with a null LegalizerInfo, it never
actually ran. Also fixes the legality checks to keep the tests passing.

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

[mlir][interfaces] Add ShapedDimOpInterface

This interface is implemented by memref.dim and tensor.dim. This change makes it possible to remove a build dependency of the Affine dialect on the Tensor dialect (and maybe also the MemRef dialect in the future).

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

[ELF] Replace some config->ekind with file->ekind. NFC

Revert "Add APFloat and MLIR type support for fp8 (e5m2)."

Breaks bots https://lab.llvm.org/buildbot/#/builders/37/builds/17086

This reverts commit 2dc68b5398258c7a0cf91f10192d058e787afcdf.

[ELF] Move init from ELFFileBase constructor to a separate function. NFC

[mlir][shape] add outline-shape-computation pass

Add outline-shape-computation pass. This pass his pass outlines the
shape computation part in high level IR by adding shape.func and
populate corresponding mapping information into ShapeMappingAnalysis.

Reviewed By: jpienaar

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

[ELF] Remove redundant getELFKind call. NFC

[ELF] Simplify addFile. NFC

[mlir][linalg][NFC] Drop emitAccessorPrefix from Linalg dialect

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

[gn build] Port 71410fd2c065

Revert "[libc++] Implement P0591R4 (Utility functions to implement uses-allocator construction)"

Breaks ubsan tests https://lab.llvm.org/buildbot/#/builders/85/builds/11131

This reverts commit 099384dcea49f5f4b0dc7e615c9845bf9baad4bc.

Add APFloat and MLIR type support for fp8 (e5m2).

This is a first step towards high level representation for fp8 types
that have been built in to hardware with near term roadmaps. Like the
BFLOAT16 type, the family of fp8 types are inspired by IEEE-754 binary
floating point formats but, due to the size limits, have been tweaked in
various ways in order to maximally use the range/precision in various
scenarios. The list of variants is small/finite and bounded by real
hardware.

This patch introduces the E5M2 FP8 format as proposed by Nvidia, ARM,
and Intel in the paper: https://arxiv.org/pdf/2209.05433.pdf

As the more conformant of the two implemented datatypes, we are plumbing
it through LLVM's APFloat type and MLIR's type system first as a
template. It will be followed by the range optimized E4M3 FP8 format
described in the paper. Since that format deviates further from the
IEEE-754 norms, it may require more debate and implementation
complexity.

Given that we see two parts of the FP8 implementation space represented
by these cases, we are recommending naming of:

* `F8M<N>` : For FP8 types that can be conceived of as following the
  same rules as FP16 but with a smaller number of mantissa/exponent
  bits. Including the number of mantissa bits in the type name is enough
  to fully specify the type. This naming scheme is used to represent
  the E5M2 type described in the paper.
* `F8M<N>F` : For FP8 types such as E4M3 which only support finite
  values.

The first of these (this patch) seems fairly non-controversial. The
second is previewed here to illustrate options for extending to the
other known variant (but can be discussed in detail in the patch
which implements it).

Many conversations about these types focus on the Machine-Learning
ecosystem where they are used to represent mixed-datatype computations
at a high level. At that level (which is why we also expose them in
MLIR), it is important to retain the actual type definition so that when
lowering to actual kernels or target specific code, the correct
promotions, casts and rescalings can be done as needed. We expect that
most LLVM backends will only experience these types as opaque `I8`
values that are applicable to some instructions.

MLIR does not make it particularly easy to add new floating point types
(i.e. the FloatType hierarchy is not open). Given the need to fully
model FloatTypes and make them interop with tooling, such types will
always be "heavy-weight" and it is not expected that a highly open type
system will be particularly helpful. There are also a bounded number of
floating point types in use for current and upcoming hardware, and we
can just implement them like this (perhaps looking for some cosmetic
ways to reduce the number of places that need to change). Creating a
more generic mechanism for extending floating point types seems like it
wouldn't be worth it and we should just deal with defining them one by
one on an as-needed basis when real hardware implements a new scheme.
Hopefully, with some additional production use and complete software
stacks, hardware makers will converge on a set of such types that is not
terribly divergent at the level that the compiler cares about.

(I cleaned up some old formatting and sorted some items for this case:
If we converge on landing this in some form, I will NFC commit format
only changes as a separate commit)

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

[RISCV] Add a LocalStackSlotAllocation test

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

[gn build] Port a6e1080b87db

Revert "[libc++][ranges]Refactor `copy{,_backward}` and `move{,_backward}`"

Breaks msan, asan

https://lab.llvm.org/buildbot/#/builders/5/builds/27904

This reverts commit 005916de58f73aa5c4264c084ba7b0e21040d88f.

[ELF] Add LLVM_LIBRARY_VISIBILITY to some global variables. NFC

[flang] Introduce fir.class type

Introduce a new ClassType for polymorphic
entities. A fir.class type is similar to a fir.box type in
many ways and is also base on the BaseBoxType.

This patch is part of the implementation of the poltymorphic
entities.
https://github.com/llvm/llvm-project/blob/main/flang/docs/PolymorphicEntities.md

Depends on D134956

Reviewed By: jeanPerier

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

[flang] Introduce BaseBoxType

Introduce a BaseBoxType to be used by BoxType and
the a new ClassType that is introduced in a follow up patch.

This patch is part of the implementation of the poltymorphic
entities.
https://github.com/llvm/llvm-project/blob/main/flang/docs/PolymorphicEntities.md

Reviewed By: PeteSteinfeld

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

[llvm-objdump][test] Improve address test

[libc++] Updates generated transitve includes.

This should fix the CI.

[InstCombine] convert mul by negative-pow2 to negate and shift

This is an unusual canonicalization because we create an extra instruction,
but it's likely better for analysis and codegen (similar reasoning as D133399).

InstCombine::Negator may create this kind of multiply from negate and shift,
but this should not conflict because of the narrow negation.

I don't know how to create a fully general proof for this kind of transform in
Alive2, but here's an example with bitwidths similar to one of the regression
tests:
https://alive2.llvm.org/ce/z/J3jTjR

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

[ValueTracking] peek through fpext in isKnownNeverInfinity()

https://alive2.llvm.org/ce/z/BkNoRW

[InstSimplify] add tests for FP infinity compare with fpext; NFC

[ARM] Add lowering for bf16 neon vtrn, vzup and vuzp.

These go via Dag2Dag, which are better based on element sizes not the
exact element types.

[ARM] More bf16 shuffle handling, including perfect shuffles.

[ConstraintElimination] Update Changed status in ssub simplification.

Update tryToSimplifyOverflowMath to indicate whether the function made
any changes to the IR.