E.g.:

```
%2 = memref.alloc() {alignment = 128 : i64} : memref<256x256xf32>
%3 = memref.alloc() {alignment = 128 : i64} : memref<256x256xf32>

// ... (%3 is not written to)

linalg.copy(%3, %2) : memref<256x256xf32>, memref<256x256xf32>
vector.transfer_write %11, %2[%c0, %c0] {in_bounds = [true, true]} : vector<256x256xf32>, memref<256x256xf32>
```

Avoid copies of %3 if %3 came directly from an InitTensorOp.

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

This is a first step towards addressing the last remaining limitation of
the VPlan version of sinkScalarOperands: the legacy version can
partially sink operands. For example, if a GEP has uniform users outside
the sink target block, then the legacy version will sink all scalar
GEPs, other than the one for lane 0.

This patch works towards addressing this case in the VPlan version by
detecting such cases and duplicating the sink candidate. All users
outside of the sink target will be updated to use the uniform clone.

Note that this highlights an issue with VPValue naming. If we duplicate
a replicate recipe, they will share the same underlying IR value and
both VPValues will have the same name ir<%gep>.

Reviewed By: Ayal

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

[X86][InlineAsm] Use mem size information (*word ptr) for "global variable + registers" memory expression in inline asm.

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

Create a new document that explain both stages of the process in a single
place, merge and deduplicate the content from the two previous documents. Also
extend the documentation to account for the recent changes in pass structure
due to standard dialect splitting and translation being more flexible.

Reviewed By: aartbik

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

Update the doc due to recent path changes an point to a helper script.

G_PTR_ADD (G_PTR_ADD X, C), Y) -> (G_PTR_ADD (G_PTR_ADD(X, Y), C)

Improves CTMark -Os on AArch64:

Program            before after  diff
           sqlite3 286932 287024  0.0%
                kc 432512 432508 -0.0%
             SPASS 412788 412764 -0.0%
    pairlocalalign 249460 249416 -0.0%
            bullet 475740 475512 -0.0%
    7zip-benchmark 568864 568356 -0.1%
  consumer-typeset 419088 418648 -0.1%
        tramp3d-v4 367628 367224 -0.1%
          clamscan 383184 382732 -0.1%
            lencod 430028 429284 -0.2%
Geomean difference               -0.1%

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

Added '-print-pipeline-passes' printing of parameters for those passes
declared with *_WITH_PARAMS macro in PassRegistry.def.

Note that it only prints the parameters declared inside *_WITH_PARAMS as
in a few cases there appear to be additional parameters not parsable.

The following passes are now covered (i.e. all of those with *_WITH_PARAMS in
PassRegistry.def).

LoopExtractorPass - loop-extract
HWAddressSanitizerPass - hwsan
EarlyCSEPass - early-cse
EntryExitInstrumenterPass - ee-instrument
LowerMatrixIntrinsicsPass - lower-matrix-intrinsics
LoopUnrollPass - loop-unroll
AddressSanitizerPass - asan
MemorySanitizerPass - msan
SimplifyCFGPass - simplifycfg
LoopVectorizePass - loop-vectorize
MergedLoadStoreMotionPass - mldst-motion
GVN - gvn
StackLifetimePrinterPass - print<stack-lifetime>
SimpleLoopUnswitchPass - simple-loop-unswitch

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

This check should ensure we don't reproduce the problem fixed by
02df443d

More accurately, it checks every llvm::Any::TypeId symbol in libLLVM-x.so and
make sure they have weak linkage and are not local to the library, which would
lead to duplicate definition if another weak version of the symbol is defined in
another linked library.

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

Summary: This patch implements parsing sections for obj2yaml on AIX.

Reviewed By: jhenderson

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

Invalid frame addresses exist in call stack samples due to bad unwinding. This could happen to frame-pointer-based unwinding and the callee functions that do not have the frame pointer chain set up. It isn't common when the program is built with the frame pointer omission disabled, but can still happen with third-party static libs built with frame pointer omitted.

Reviewed By: wenlei

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

This reverts commit 81f8ad17.
This seems to break the shared libs build
(linaro-flang-aarch64-sharedlibs bot) with:

  undefined reference to `Fortran::semantics::IsCoarray(Fortran::semantics::Symbol const&)

(from tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/tools.cpp.o)

When linking lib/libFortranEvaluate.so.14git

This seems in-line with the intent and how we build tools around it.
Update the description for the flag accordingly.
Also use an injected thread pool in MLIROptMain, now we will create
threads up-front and reuse them across split buffers.

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

Both copy/alloc ops are using memref dialect after this change.

Reviewed By: silvas, mehdi_amini

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

This reverts commit 49992c04.
The test is still failing on Windows, see comments on https://reviews.llvm.org/D108893

The fmul is a canonicalizing operation, and fneg is not so this would
break denormals that need flushing and also would not quiet signaling
nans. Fold to fsub instead, which is also canonicalizing.

Pseudo probe instrumentation was missing from O0 build. It is needed in cases where some source files are built in O0 while the others are built in optimize mode.

Reviewed By: wenlei, wlei, wmi

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

Rather than depending on the hex dump from obj2yaml. Now the test shows the
expected function body in a human readable format.

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

This simple heuristic uses the estimated live range length combined
with the number of registers in the class to switch which heuristic to
use. This was taking the raw number of registers in the class, even
though not all of them may be available. AMDGPU heavily relies on
dynamically reserved numbers of registers based on user attributes to
satisfy occupancy constraints, so the raw number is highly misleading.

There are still a few problems here. In the original testcase that
made me notice this, the live range size is incorrect after the
scheduler rearranges instructions, since the instructions don't have
the original InstrDist offsets. Additionally, I think it would be more
appropriate to use the number of disjointly allocatable registers in
the class. For the AMDGPU register tuples, there are a large number of
registers in each tuple class, but only a small fraction can actually
be allocated at the same time since they all overlap with each
other. It seems we do not have a query that corresponds to the number
of independently allocatable registers. Relatedly, I'm still debugging
some allocation failures where overlapping tuples seem to not be
handled correctly.

The test changes are mostly noise. There are a handful of x86 tests
that look like regressions with an additional spill, and a handful
that now avoid a spill. The worst looking regression is likely
test/Thumb2/mve-vld4.ll which introduces a few additional
spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll
shows a massive improvement by completely eliminating a large number
of spills inside a loop.

The last user has been removed from llvm-zorg for Android.

Do not generate FillOps when these would be entirely overwritten.

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

ConstantOffsetExtractor::Find was infinitely recursing on the add
referencing itself.

This isn't really an AMDGPU specific attribute and could be moved to
generic code. It's also important to include the word uniform in the
name.

Added 'this_image()' to the list of functions that are evaluated as intrinsic.
Added IsCoarray functions to determine if an expression is a coarray (corank > 1).

Added save attribute to coarray variables in test file, this_image.f90.

reviewers: klausler, PeteSteinfeld

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

This header aren't needed anymore: MLIR is using a thread pool
injected in the context instead of a global one.

Laying more foundation for full template name rebuilding - more complex
type printing benefits from an object to carry some state rather than
passing it around as parameters to every function.

Reviewed By: ftynse

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

This fixes a violation of the wrap flag rules introduced in c4048d8f. As noted in the original review, the NUW is legal to infer from the structure of the replacee, but a) there's no test coverage, and b) this should be done generically for all multiplies.

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

Upstream lldb support for summarizing BLRAx and LDRAx auth failures.

rdar://41615322

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

This is an attempt to define what the current semantics are closest too.  Unfortunately, the current implementation does appear to be inconsistent with all semantic variants we've considered.  This semantics is the one which seems to be closest to the spirit of the code, and that matched several long time contributors mental models of how the code "should work".

https://bugs.llvm.org/show_bug.cgi?id=51817 tracks the list of currently known violations of these rules.  A series of follow up patches will be addressing each now that we've defined them to be bugs.

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

Visibility options currently have limited support on AIX and may cause warnings or errors
depending on the build compiler used.

Reviewed By: ZarkoCA

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

This reverts commit b7b4ebbc.

Reason: This breaks several code-size tests in Emscripten test suite
because this exports `emscripten_longjmp` for programs that didn't do it
before.

Use GCNHazardRecognizer in postra sched.
Updated tests for the new schedules.

Reviewed By: arsenm

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

Change-Id: Ia86ba2ae168f12fb34b4d8efdab491f84d936cde

This matters for example for the iPhoneSimulator14.0.sdk, which has
a System/Library/Frameworks/UIKit.framework/UIKit that has
LC_BUILD_VERSION with minos of 14.0, so linking against that file
will produce warnings like:

   .../iPhoneSimulator14.0.sdk/System/Library/Frameworks/UIKit.framework/UIKit
   has version 14.0.0, which is newer than target minimum of 12.0.0

when targeting x86_64-apple-ios12.0-simulator. That doens't happen when
linking against UIKit.tbd instead, obviously.

Linking with RC_TRACE_DYLIB_SEARCHING=1 shows that ld64 also searches
the tbd file first, and we already get that right for non-framework
dylibs.

Fixes crbug.com/1249456.

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