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

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

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

Reviewed By: ktras

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

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

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

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

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

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
fcd549a7 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

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

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

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.

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.

Reviewed By: rsuderman

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

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

Reviewed By: Peiming

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

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

The field is no unused and can be removed.

Reviewed By: aartbik

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

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

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

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

Add MLIR upstream C api library definition.

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

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

Reviewed By: nikic, nickdesaulniers, xbolva00

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

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

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

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

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

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

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

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 16544cbe

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

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.

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

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

Also added global-isel coverage for the same file.

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.

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

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

Reviewed By: DavidSpickett

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