Reviewed By: michaelrj

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

These appear in some sections, such as DWARF tables, since
RuntimeDyldELF explicitly maps to this as a sentinel value:
https://github.com/llvm/llvm-project/blob/29d1fba7b5335d969e3e5daa84b7a25cd1fa75ef/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp#L1199

That could then be a source of problems if it tried to examine these
sections (for example, with either setProcessAllSections(true) or ORCv2 on i686).

Replaces https://reviews.llvm.org/D89241

Reviewed By: lhames, vchuravy

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

[RISCV] Add test case to show incorrect matching to sroiw when the or mask does not have 1s in the upper 32 bits.

The matching code for sroiw is truncating the mask to 32 bits before
checking its value. We need to check all 64 bits.

Results of convergent operations are implicitly affected by the
enclosing control flows and should not be hoisted out of arbitrary
loops.

Patch by Xiaoqing Wu <xiaoqing_wu@apple.com>

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

Sometimes builds will fail with errors like:

```
In file included from /build/external/llvm-project/lldb/source/Symbol/SwiftASTContext.cpp:52:
In file included from /build/external/swift/include/swift/IRGen/Linking.h:22:
In file included from /build/external/swift/include/swift/SIL/SILFunction.h:24:
In file included from /build/external/swift/include/swift/SIL/SILBasicBlock.h:23:
In file included from /build/external/swift/include/swift/SIL/SILInstruction.h:21:
In file included from /build/external/swift/include/swift/AST/Builtins.h:24:
**/build/external/llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 'llvm/IR/Attributes.inc' file not found**
**^~~~~~~~~~~~~~~~~~~~~~~~**
```
This change ensures the `Attributes.inc` file is generated before building `SwiftASTContext.cpp`.

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

The PyOpOperands container was erroneously constructing objects for
individual operands as PyOpResult. Operands in fact are just values,
which may or may not be results of another operation. The code would
eventually crash if the operand was a block argument. Add a test that
exercises the behavior that previously led to crashes.

Reviewed By: stellaraccident

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

This reverts commit 80fe2f61.

Broke linkage with GNU ld. See original review thread for more details.

This patch fixes potential division by 0 in case hwloc does not
recognize cores (or architecture has no cores).

Patch by Andrey Churbanov

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

`populateFreelist` was more complicated that it needed to be. We used
to call to `populateBatches` that would do some internal shuffling and
add pointers one by one to the batches, but ultimately this was not
needed. We can get rid of `populateBatches`, and do processing in
bulk. This doesn't necessarily make things faster as this is not on the
hot path, but it makes the function cleaner.

Additionally clean up a couple of items, like `UNLIKELY`s and setting
`Exhausted` to `false` which can't happen.

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

Avoid an expensive isKnownNonZero() call - this is a small cleanup before moving the extra NSW functionality from computeKnownBitsMul into KnownBits::computeForMul.

We were discussing on discord regarding the need for extension-based systems like Python to dynamically link against MLIR (or else you can only have one extension that depends on it). Currently, when I set that up, I piggy-backed off of the flag that enables build libLLVM.so and libMLIR.so and depended on libMLIR.so from the python extension if shared library building was enabled. However, this is less than ideal.

In the current setup, libMLIR.so exports both all symbols from the C++ API and the C-API. The former is a kitchen sink and the latter is curated. We should be splitting them and for things that are properly factored to depend on the C-API, they should have the option to *only* depend on the C-API, and we should build that shared library no matter what. Its presence isn't just an optimization: it is a key part of the system.

To do this right, I needed to:

* Introduce visibility macros into mlir-c/Support.h. These should work on both *nix and windows as-is.
* Create a new libMLIRPublicAPI.so with just the mlir-c object files.
* Compile the C-API with -fvisibility=hidden.
* Conditionally depend on the libMLIR.so from libMLIRPublicAPI.so if building libMLIR.so (otherwise, also links against the static libs and will produce a mondo libMLIRPublicAPI.so).
* Disable re-exporting of static library symbols that come in as transitive deps.

This gives us a dynamic linked C-API layer that is minimal and should work as-is on all platforms. Since we don't support libMLIR.so building on Windows yet (and it is not very DLL friendly), this will fall back to a mondo build of libMLIRPublicAPI.so, which has its uses (it is also the most size conscious way to go if you happen to know exactly what you need).

Sizes (release/stripped, Ubuntu 20.04):

Shared library build:
	libMLIRPublicAPI.so: 121Kb
	_mlir.cpython-38-x86_64-linux-gnu.so: 1.4Mb
	mlir-capi-ir-test: 135Kb
	libMLIR.so: 21Mb

Static build:
	libMLIRPublicAPI.so: 5.5Mb (since this is a "static" build, this includes the MLIR implementation as non-exported code).
	_mlir.cpython-38-x86_64-linux-gnu.so: 1.4Mb
	mlir-capi-ir-test: 44Kb

Things like npcomp and circt which bring their own dialects/transforms/etc would still need the shared library build and code that links against libMLIR.so (since it is all C++ interop stuff), but hopefully things that only depend on the public C-API can just have the one narrow dep.

I spot checked everything with nm, and it looks good in terms of what is exporting/importing from each layer.

I'm not in a hurry to land this, but if it is controversial, I'll probably split off the Support.h and API visibility macro changes, since we should set that pattern regardless.

Reviewed By: mehdi_amini, benvanik

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

The strictfp metadata was added to the casting AST nodes in D85960, but
we aren't using that metadata yet. This patch adds that support.

In order to avoid lots of ad-hoc passing around of the strictfp bits I
updated the IRBuilder when moving from a function that has the Expr* to a
function that lacks it. I believe we should switch to this pattern to keep
the strictfp support from being overly invasive.

For the purpose of testing that we're picking up the right metadata, I
also made my tests use a pragma to make the AST's strictfp metadata not
match the global strictfp metadata. This exposes issues that we need to
deal with in subsequent patches, and I believe this is the right method
for most all of our clang strictfp tests.

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

Some of these were found by running clang-format over the generated
code, although that complains about far more issues than I have fixed
here.

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

Treat any identifier as a potential exp target and diagnose them all the
same way as "invalid exp target"s.

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

Previously we just shadowed the original implementation with a virtual
declaration - which is really bugprone in a long run.

This patch marks `CallEvent::getOriginExpr` virtual to let subclasses
override it's behavior.
At the same time, I checked all virtual functions of this class hierarchy
to make sure we don't suffer from this elsewhere.
Removes redundant declarations of `virtual` if `override` is already present.

In theory, this patch is a functional change, but no tests were broken.
I suspect that there were no meaningful changes in behavior in the
subclasses compared to the shadowed `CallEvent::getOriginExpr`.

That being said, I had a hard time coming up with unit-tests covering this.
Motivation: https://reviews.llvm.org/D74735#2370909

Reviewed By: NoQ

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

Continue to dump and match on explicit template specializations, but
omit explicit instantiation declarations and definitions.

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

idiv: There is no difference between Armv7m and Thumbv7M
behaviour so the specific CHECKs are not needed.
The errors for Armv7-a and Thumbv7-a will always
include "ARM" or "THUMB" respectively so they need their
own CHECK prefix, making CHECK-V7 redundant.

mp: Behaviour is dependent on whether the triple is v6/v7/v7M
regardless of being Arm or Thumb. So we don't need the more
specific CHECK-ARMv7M etc.

simd: Errors are either v7 only, or v7 and v8 so CHECK-V8
is not needed.

fp: Same as simd

Reviewed By: ostannard

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

See https://github.com/google/oss-fuzz/issues/4586.

As pointed out in post-commit review in that commit

llvm.coro.id.async lowering: Parameterize how-to restore the current's continutation context and restart the pipeline after splitting

The `llvm.coro.suspend.async` intrinsic takes a function pointer as its
argument that describes how-to restore the current continuation's
context from the context argument of the continuation function. Before
we assumed that the current context can be restored by loading from the
context arguments first pointer field (`first_arg->caller_context`).

This allows for defining suspension points that reuse the current
context for example.

Also:

llvm.coro.id.async lowering: Add llvm.coro.preprare.async intrinsic

Blocks inlining until after the async coroutine was split.

Also, change the async function pointer's context size position

   struct async_function_pointer {
     uint32_t relative_function_pointer_to_async_impl;
     uint32_t context_size;
   }

And make the position of the `async context` argument configurable. The
position is specified by the `llvm.coro.id.async` intrinsic.

rdar://70097093

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

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

V(m)regs where defined before CSR_preserve_all was, add them now.

Reviewed By: kaz7

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

This test was added in 7f38812d
and all the other tests make use of the COMMONIR check. So I think
this was left in by mistake for this particular test.

Reviewed By: kpn

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

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

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

Use positive logic (i.e. llgs_platform/debugserver_platform) for
indicating which platforms use the particular server variant.
Deduplicate the lists — it is rather expected that none of the platforms
using LLGS would use debugserver.

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

Prepare for supporting  different calling conventions by factoring out
things into CC-dependent selection functions (getParamCC, getReturnCC).

Reviewed By: kaz7

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

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

Summary:
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.

Also, add XFAIL markup to flag expected errors.

Currently we do not consider incoming values of PHIs as roots for SLP
vectorization. This means we miss scenarios like the one in the test
case and PR47670.

It appears quite straight-forward to consider incoming values of PHIs as
roots for vectorization, but I might be missing something that makes
this problematic.

In terms of vectorized instructions, this applies to quite a few
benchmarks across MultiSource/SPEC2000/SPEC2006 on X86 with -O3 -flto

    Same hash: 185 (filtered out)
    Remaining: 52
    Metric: SLP.NumVectorInstructions

    Program                                        base    patch   diff
     test-suite...ProxyApps-C++/HPCCG/HPCCG.test     9.00   27.00  200.0%
     test-suite...C/CFP2000/179.art/179.art.test     8.00   22.00  175.0%
     test-suite...T2006/458.sjeng/458.sjeng.test    14.00   30.00  114.3%
     test-suite...ce/Benchmarks/PAQ8p/paq8p.test    11.00   18.00  63.6%
     test-suite...s/FreeBench/neural/neural.test    12.00   18.00  50.0%
     test-suite...rimaran/enc-3des/enc-3des.test    65.00   95.00  46.2%
     test-suite...006/450.soplex/450.soplex.test    63.00   89.00  41.3%
     test-suite...ProxyApps-C++/CLAMR/CLAMR.test   177.00  250.00  41.2%
     test-suite...nchmarks/McCat/18-imp/imp.test    13.00   18.00  38.5%
     test-suite.../Applications/sgefa/sgefa.test    26.00   35.00  34.6%
     test-suite...pplications/oggenc/oggenc.test   100.00  133.00  33.0%
     test-suite...6/482.sphinx3/482.sphinx3.test   103.00  134.00  30.1%
     test-suite...oxyApps-C++/miniFE/miniFE.test   169.00  213.00  26.0%
     test-suite.../Benchmarks/Olden/tsp/tsp.test    59.00   73.00  23.7%
     test-suite...TimberWolfMC/timberwolfmc.test   503.00  622.00  23.7%
     test-suite...T2006/456.hmmer/456.hmmer.test    65.00   79.00  21.5%
     test-suite...libquantum/462.libquantum.test    58.00   68.00  17.2%
     test-suite...ternal/HMMER/hmmcalibrate.test    84.00   98.00  16.7%
     test-suite...ications/JM/ldecod/ldecod.test   351.00  401.00  14.2%
     test-suite...arks/VersaBench/dbms/dbms.test    52.00   57.00   9.6%
     test-suite...ce/Benchmarks/Olden/bh/bh.test   118.00  128.00   8.5%
     test-suite.../Benchmarks/Bullet/bullet.test   6355.00 6880.00  8.3%
     test-suite...nsumer-lame/consumer-lame.test   480.00  519.00   8.1%
     test-suite...000/183.equake/183.equake.test   226.00  244.00   8.0%
     test-suite...chmarks/Olden/power/power.test   105.00  113.00   7.6%
     test-suite...6/471.omnetpp/471.omnetpp.test    92.00   99.00   7.6%
     test-suite...ications/JM/lencod/lencod.test   1173.00 1261.00  7.5%
     test-suite...0/253.perlbmk/253.perlbmk.test    55.00   59.00   7.3%
     test-suite...oxyApps-C/miniAMR/miniAMR.test    92.00   98.00   6.5%
     test-suite...chmarks/MallocBench/gs/gs.test   446.00  473.00   6.1%
     test-suite.../CINT2006/403.gcc/403.gcc.test   464.00  491.00   5.8%
     test-suite...6/464.h264ref/464.h264ref.test   998.00  1055.00  5.7%
     test-suite...006/453.povray/453.povray.test   5711.00 6007.00  5.2%
     test-suite...FreeBench/distray/distray.test   102.00  107.00   4.9%
     test-suite...:: External/Povray/povray.test   4184.00 4378.00  4.6%
     test-suite...DOE-ProxyApps-C/CoMD/CoMD.test   112.00  117.00   4.5%
     test-suite...T2006/445.gobmk/445.gobmk.test   104.00  108.00   3.8%
     test-suite...CI_Purple/SMG2000/smg2000.test   789.00  819.00   3.8%
     test-suite...yApps-C++/PENNANT/PENNANT.test   233.00  241.00   3.4%
     test-suite...marks/7zip/7zip-benchmark.test   417.00  428.00   2.6%
     test-suite...arks/mafft/pairlocalalign.test   627.00  643.00   2.6%
     test-suite.../Benchmarks/nbench/nbench.test   259.00  265.00   2.3%
     test-suite...006/447.dealII/447.dealII.test   4641.00 4732.00  2.0%
     test-suite...lications/ClamAV/clamscan.test   106.00  108.00   1.9%
     test-suite...CFP2000/177.mesa/177.mesa.test   1639.00 1664.00  1.5%
     test-suite...oxyApps-C/RSBench/rsbench.test    66.00   65.00  -1.5%
     test-suite.../CINT2000/252.eon/252.eon.test   3416.00 3444.00  0.8%
     test-suite...CFP2000/188.ammp/188.ammp.test   1846.00 1861.00  0.8%
     test-suite.../CINT2000/176.gcc/176.gcc.test   152.00  153.00   0.7%
     test-suite...CFP2006/444.namd/444.namd.test   3528.00 3544.00  0.5%
     test-suite...T2006/473.astar/473.astar.test    98.00   98.00   0.0%
     test-suite...frame_layout/frame_layout.test    NaN     39.00   nan%

On ARM64, there appears to be a slight regression on SPEC2006, which
might be interesting to investigate:

   test-suite...T2006/473.astar/473.astar.test   0.9%

Reviewed By: ABataev

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

Tests must not modify the source tree.

This file is only ever looking for errors so we can
just use the default CHECK.

Reviewed By: sdesmalen

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

It was unused when added and the CHECK-ERROR lines
cover the possible outputs.

Reviewed By: ostannard

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

Optimize address calculations using LEA/LEASL instructions.
Update comments in VEISelLowering.cpp also.  Update an
existing regression test optimized by this modification.

Reviewed By: simoll

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

Claim to not have any vector support to dissuade SLP, LV and friends
from generating SIMD IR for the VE target.  We will take this back once
vector isel is stable.

Reviewed By: kaz7, fhahn

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