Fold dim ops of linalg.tiled_loop results to dim ops of the respective iter args if the loop is shape preserving.

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

Reviewed By: cryptoad

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

Run a small analysis to see if the runtime type of the iter_arg is changing. Fold only if the runtime type stays the same. (Same as `DimOfIterArgFolder` in SCF.)

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

As of 741fabc222f226d34d806056b804244b012853b, polly builders are
failing from this error. The signiature is slightly different and
accepts a ScalarEvolution reference instead. This should fix the polly
builders.

The cross-compiled lldb-server targets are added to the lldb deps if
Android cross compilation is enabled.

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

On Linux, LLDB depends on lldb-server at runtime (on Mac, the dependency on
a debug server presumably comes via the system debugserver), so I added it
to deps.

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

When tiling a LinalgOp, extract_slice/insert_slice pairs are inserted. To avoid going out-of-bounds when the tile size does not divide the shape size evenly (at the boundary), AffineMin ops are inserted. Some ops have assumptions regarding the dimensions of inputs/outputs. E.g., in a `A * B` matmul, `dim(A, 1) == dim(B, 0)`. However, loop bounds use either `dim(A, 1)` or `dim(B, 0)`.

With this change, AffineMin ops are expressed in terms of loop bounds instead of tensor sizes. (Both have the same runtime value.) This simplifies canonicalizations.

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

This reverts commit 407e07aa.

Reverting since this seems to break OpenMP builds and our clang
builders. See thread on https://reviews.llvm.org/D107895.

This moves one mid-size function out of line, inlines the
trivial tcAnd/tcOr/tcXor/tcComplement methods into their only
caller, and moves the magic/umagic functions into SelectionDAG
since they are implementation details of its algorithm. This
also removes the unit tests for magic, but these are already
tested in the divide lowering logic for various targets.

This also upgrades some C style comments to C++.

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

Similar to other code which handles creating the function frame.

If LR isn't live-in to the block that we're inserting the call into, we'll get
a MachineVerifier error.

This is a port of a combine which matches a pattern where a wide type scalar
value is stored by several narrow stores. It folds it into a single store or
a BSWAP and a store if the targets supports it.

Assuming little endian target:
 i8 *p = ...
 i32 val = ...
 p[0] = (val >> 0) & 0xFF;
 p[1] = (val >> 8) & 0xFF;
 p[2] = (val >> 16) & 0xFF;
 p[3] = (val >> 24) & 0xFF;
=>
 *((i32)p) = val;

On CTMark AArch64 -Os this results in a good amount of savings:

Program            before        after       diff
             SPASS 412792       412788       -0.0%
                kc 432528       432512       -0.0%
            lencod 430112       430096       -0.0%
  consumer-typeset 419156       419128       -0.0%
            bullet 475840       475752       -0.0%
        tramp3d-v4 367760       367628       -0.0%
          clamscan 383388       383204       -0.0%
    pairlocalalign 249764       249476       -0.1%
    7zip-benchmark 570100       568860       -0.2%
           sqlite3 287628       286920       -0.2%
Geomean difference                           -0.1%

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

This is making a tablegen crash with a more friendly error.

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

This ensures error messages from gtest includes the raw text of both
sides of the comparison - otherwise all gtest can report is the text of
the expression source, without any information about the values or how
they differ.

For use with APIs that want to report the file name in a different
syntactic form, have other knowledge of the filename, etc.

It's a common error in an API - to try to open an empty file, so it
seems like a reasonable FileError to produce "hey, you tried to open an
empty file" and to handle it the same way as any other file error.

This moves all the private implementation details to the bottom of
the header, and pushes all the "make an APInt" stuff up to the top.
This is in prep for making other changes to spiff up APInt a bit.

- Make flto an alias of flto=full.
- Make foffload-lto an alias of foffload-lto=full.
- Make flto_EQ_jobserver, flto_EQ_auto aliases of flto=full,
  since they are being treated as full lto right now.
- Clean up the code for parseLTOMode and setLTOMode.
- Replace uses of OPT_flto with OPT_flto_EQ since they alias now.

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

Change-Id: I5d867db83a680434fba5c8d85c9a83135d3b81ee

I forgot that we run `check-runtimes-x86_64-unknown-linux-gnu`, which
will run all compiler-rt tests also even though we are currently not in
a state where we can run them all yet. Remove this for now to fix our CI
builders.

This reverts commit d2d2e5ea.

- Make flto an alias of flto=full.
- Make foffload-lto an alias of foffload-lto=full.
- Make flto_EQ_jobserver, flto_EQ_auto aliases of flto=full,
  since they are being treated as full lto right now.
- Clean up the code for parseLTOMode and setLTOMode.
- Replace uses of OPT_flto with OPT_flto_EQ since they alias now.

Change-Id: Iea5338c20cb800b43529b20745e92600e2cfd2b1

We were returning a tuple when all but one caller only cared about one piece of the return value.  That one caller can inline the complexity, and we can simplify all other uses.

Previously the CodeExtractor created exit stubs, and the subsequent return value of the outlined function based on the order of out-of-region blocks after splitting any phi nodes, and collecting the blocks to be outlined. This could cause differences in order if there was a difference of exit block phi nodes between the two regions. This patch moves the collection of the output target blocks to be before this occurs, so that the assignment of target block to output value will be the same, regardless of the contents of the output block.

Reviewers: paquette, roelofs

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

Rewrite this test to not rely on volatile stores in a large function,
just use separate functions like any other test would.

Reviewed By: asbirlea

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

Since i128 isn't a legal C type on RV32, I don't believe
libgcc implements these functions for RV32. compiler-rt
does implement them because i128 support is enabled
in order to handle long double.

This is consistent with 32-bit X86 and ARM.

Reviewed By: efriedma

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

Users of delinearization assume that the the offset into the array element is zero. In most cases it will indeed be zero, but if it is not, the delinearization has to fail since it violates that assumption without the API even allowing to signal to the caller that the by offset is non-zero.

This bug caused Polly to miscompile blender (526.blender_r from SPEC CPU 2017) in -polly-process-unprofitable mode. The SCEV expression incorrectly delinearized has been reduced in the test case byte_offset.ll. The dropped offset into the array element of size 4 (a float) is ((sext i32 %mul7.i4534 to i64) + {(sext i32 %i1 to i64),+,((sext i32 (1 + ((1 + %shl.i.i) * (1 + %shl.i.i)) + %shl.i.i) to i64) * (sext i32 %i1 to i64))}<%for.body703>). This significant component was just dropped, and the wrong pointer was computed when regenerating code from the remaining delinearized subscripts. This occurred during blender's subsurface scattering implementation. As a result, blender's rendering diverged from the reference image.

Patch D108885 would also fix the API.

Reviewed By: bmahjour

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

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

These paths are needed when building with per-target runtime directories.

(It's possible to fix this by manually setting these when invoking
cmake, but one isn't supposed to need to do that.)

Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's
also unset in this case) even if it isn't specifically needed by the
per-target runtime configuration.

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

Since we might end up using multiple threads when logging information in the DWARFTransformer, the handleDie() method must use the supplied stream named "OS" when logging warnings and errors. When we use multiple threads, we log to a thread specific stream buffer and then use a mutex to ensure our output doesn't overlap when we emit warnings and errors after a thread is done.

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

Make sure there's a value for the shared_cache_base_address key exists
in the dictionary before trying to dereference the value.

rdar://76894476

The OrigPtr argument is not used in tree.

This patch (e4635e63) fixed a bug where a newly generated/reused
constant wouldn't dominate a folded operation.  It did so by calling
isBeforeInBlock to move the constant around on demand.  This introduced
a significant compile time regression, because "isBeforeInBlock" is
O(n) in the size of a block the first time it is called, and the cache
is invalidated any time canonicalize changes something big in the block.

This fixes LLVM PR51738 and this CIRCT issue:
https://github.com/llvm/circt/issues/1700

This does affect the order of constants left in the top of a block,
I staged in the testsuite changes in rG42431b82.

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

by commit 585c594d

Make the following changes in order to support opaque pointers in SROA:

 * Generate i8 GEPs for opaque pointers.
 * Explicitly enforce that promotable allocas only have stores of
   the alloca type -- previously this was implicitly enforced.
 * Replace a check for pointer element type with load/store type.

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

The current check for typedef is naive and doesn't deal with any convoluted cases. This patch makes use of the new 'AlignRequirement' enum field from 'TypeInfo' to determine whether or not this is an 'aligned' attribute on a typedef.

Reviewed By: rjmccall

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