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

Suggested in D113577.

Convert fir.int<kind> to their llvm equivalent type

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: clementval, awarzynski

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

This reverts commit 9deab60a.
There is a possibly unintended semantic change.

This reverts commit d73e27d9.

Convert fir.heap type to its llvm equivalent type (llvm.ptr)

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: clementval

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>

Sphinx buildbot failing.
This reverts commit 735e4332.

This patch extends the existing out-of-bounds store tests with a case
with a bigger object and multiple inbounds stores, followed by an OOB
store. The OOB store is not used to remove the inbounds stores in this
case at the moment.

- Jaro–Winkler and Sørensen–Dice should use en-dashes not regular
  dashes. In reStructuredText this is typed as `--`.
- Letters at the beginning of a sentence should be capitalized.

The source index should not be compared to zero after applying the
shift with the modulo, it must be compared to the lower bound.
Otherwise, the extent is not added in case it should and the computed
source index may be less than the lower bound, causing invalid results.

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

Some compiler-rt tests are inherently incompatible with VE because..

* No consistent denormal support on VE. We skip denormal fp inputs in builtin tests.
* `madvise` unsupported on VE.
* Instruction alignment requirements.

Reviewed By: phosek

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

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

TableGen has started warning about unused template parameters in the isel patterns.  Remove those.

Reviewed By: kaz7

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

Register uses that are MRI->isConstantPhysReg() should not inhibit
sinking transformation.

Reviewed By: StephenTozer

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

Per discussion on discord and various feature requests across bindings (Haskell and Rust bindings authors have asked me directly), we should be building a link-ready MLIR-C dylib which exports the C API and can be used without linking to anything else.

This patch:

* Adds a new MLIR-C aggregate shared library (libMLIR-C.so), which is similar in name and function to libLLVM-C.so.
* It is guarded by the new CMake option MLIR_BUILD_MLIR_C_DYLIB, which has a similar purpose/name to the LLVM_BUILD_LLVM_C_DYLIB option.
* On all platforms, this will work with both static, BUILD_SHARED_LIBS, and libMLIR builds, if supported:
  * In static builds: libMLIR-C.so will export the CAPI symbols and statically link all dependencies into itself.
  * In BUILD_SHARED_LIBS: libMLIR-C.so will export the CAPI symbols and have dynamic dependencies on implementation shared libraries.
  * In libMLIR.so mode: same as static. libMLIR.so was not finished for actual linking use within the project. An eventual relayering so that libMLIR-C.so depends on libMLIR.so is possible but requires first re-engineering the latter to use the aggregate facility.
* On Linux, exported symbols are filtered to only the CAPI. On others (MacOS, Windows), all symbols are exported. A CMake status is printed unless if global visibility is hidden indicating that this has not yet been implemented. The library should still work, but it will be larger and more likely to conflict until fixed. Someone should look at lifting the corresponding support from libLLVM-C.so and adapting. Or, for special uses, just build with `-DCMAKE_CXX_VISIBILITY_PRESET=hidden -DCMAKE_C_VISIBILITY_PRESET=hidden`.
* Includes fixes to execution engine symbol export macros to enable default visibility. Without this, the advice to use hidden visibility would have resulted in test failures and unusable execution engine support libraries.

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

Feedback from Richard Smith that the policy should be named closer to
the context its used in.

When compiler converts x87 operations to stack model, it may insert
instructions that pop top stack element. To do it the compiler inserts
instruction FSTP right after the instruction that calculates value on
the stack. It can break the code that uses FPSW set by the last
instruction. For example, an instruction FXAM is usually followed by
FNSTSW, but FSTP is inserted after FXAM. As FSTP leaves condition code
in FPSW undefined, the compiler produces incorrect code.

With this change FSTP in inserted after the FPSW consumer if the last
instruction sets FPSW.

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

This reverts commit e941fe50.

The commit in question causes:

  lld/MachO/InputFiles.cpp:916:13: error: use of undeclared identifier
  'it'

Clang seems to emit all functionAddress relocs as section relocs, but
`ld -r` can turn those relocs into symbol ones. It turns out that we
weren't handling that case correctly when the symbol was a weak def
whose definition did not prevail.

Reviewed By: #lld-macho, oontvoo

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

We don't build libcxxabi and libunwind for Windows so don't set the
corresponding variables to avoid configuration errors.

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

This trivial patch runs clang-format on some unformatted files before
doing logic changes and prevent hard to review diffs.

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

Forgot to amend D113537 with these changes before committing.

Having a separate counting method runs the risk of a mismatch between
the actual reduction method and the counting method.

Instead, create an Oracle that always returns true for shouldKeep(), run
the reduction, and count how many times shouldKeep() was called. The
module should not be modified if shouldKeep() always returns true.

Reviewed By: Meinersbur

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

Metadata operands tend to require special conditions, especially on dbg
intrinsics. We also don't have a zero value for metadata.

Replacing callee operands is a little weird, since calling undef/null
doesn't make sense. It also causes tons of invalid reductions when
reducing calls to intrinsics since only arguments to intrinsics can be
of the metadata type.

Reviewed By: Meinersbur

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

If a sysroot was specified, it would take precedence over the Android
NDK sysroot since it would appear after in the command line.

Also only build runtimes for enabled target arches. Many places have
copied this around so create and use supported_android_toolchains.

Reviewed By: pcc

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

This reverts commit c7be8b75.

Build is broken (multiple buildbots)

Add a new "operands-skip" pass whose goal is to remove instructions in the middle of dependency chains. For instance:
```
  %baseptr = alloca i32
  %arrayidx = getelementptr i32, i32* %baseptr, i32 %idxprom
  store i32 42, i32* %arrayidx
```
might be reducible to
```
  %baseptr = alloca i32
  %arrayidx = getelementptr ...  ; now dead, together with the computation of %idxprom
  store i32 42, i32* %baseptr
```
Other passes would either replace `%baseptr` with undef (operands, instructions) or move it to become a function argument (operands-to-args), both of which might fail the interestingness check.

In principle the implementation allows operand replacement with any value or instruction in the function that passes the filter constraints (same type, dominance, "more reduced"), but is limited in this patch to values that are directly or indirectly used to compute the current operand value, motivated by the example above. Additionally, function arguments are added to the candidate set which helps reducing the number of relevant arguments mitigating a concern of too many arguments mentioned in https://reviews.llvm.org/D110274#3025013.

Possible future extensions:
 * Instead of requiring the same type, bitcast/trunc/zext could be automatically inserted for some more flexibility.
 * If undef is added to the candidate set, "operands-skip"is able to produce any reduction that "operands" can do. Additional candidates might be zero and one, where the "reductive power" classification can prefer one over the other. If undefined behaviour should not be introduced, undef can be removed from the candidate set.

Recommit after resolving conflict with D112651 and reusing
shouldReduceOperand from D113532.

Reviewed By: aeubanks

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

* Depends on D111504, which provides the boilerplate for building aggregate shared libraries from installed MLIR.
* Adds a full-fledged Python example dialect and tests to the Standalone example (need to do a bit of tweaking in the top level CMake and lit tests to adapt better to if not building with Python enabled).
* Rips out remnants of custom extension building in favor of `pybind11_add_module` which does the right thing.
* Makes python and extension sources installable (outputs to src/python/${name} in the install tree): Both Python and C++ extension sources get installed as downstreams need all of this in order to build a derived version of the API.
* Exports sources targets (with our properties that make everything work) by converting them to INTERFACE libraries (which have export support), as recommended for the forseeable future by CMake devs. Renames custom properties to start with lower-case letter, as also recommended/required (groan).
* Adds a ROOT_DIR argument to `declare_mlir_python_extension` since now all C++ sources for an extension must be under the same directory (to line up at install time).
* Need to validate against a downstream or two and adjust, prior to submitting.

Downstreams will need to adapt by:

* Remove absolute paths from any SOURCES for `declare_mlir_python_extension` (I believe all downstreams are just using `${CMAKE_CURRENT_SOURCE_DIR}` here, which can just be ommitted). May need to set `ROOT_DIR` if not relative to the current source directory.
* To allow further downstreams to install/build, will need to make sure that all C++ extension headers are also listed under SOURCES for `declare_mlir_python_extension`.

Reviewed By: stephenneuendorffer, mikeurbach

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

This fixes the crash due to lacking VZEXT_MOVL support with i16.

Reviewed By: LuoYuanke, RKSimon

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

This reverts commit fa4210a9.

It causes compile failures, presumably because conflicting with another
patch landed after I checked locally.

The remaining dialects will be decoupled from ComprehensiveBufferize in separate commits.

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

With `-Os` turned on, results in 2-5% binary size reduction
(depends on the original binary). Without it, the binary size
is essentially unchanged.

Depends on D113128

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

Add a new "operands-skip" pass whose goal is to remove instructions in the middle of dependency chains. For instance:
```
  %baseptr = alloca i32
  %arrayidx = getelementptr i32, i32* %baseptr, i32 %idxprom
  store i32 42, i32* %arrayidx
```
might be reducible to
```
  %baseptr = alloca i32
  %arrayidx = getelementptr ...  ; now dead, together with the computation of %idxprom
  store i32 42, i32* %baseptr
```
Other passes would either replace `%baseptr` with undef (operands, instructions) or move it to become a function argument (operands-to-args), both of which might fail the interestingness check.

In principle the implementation allows operand replacement with any value or instruction in the function that passes the filter constraints (same type, dominance, "more reduced"), but is limited in this patch to values that are directly or indirectly used to compute the current operand value, motivated by the example above. Additionally, function arguments are added to the candidate set which helps reducing the number of relevant arguments mitigating a concern of too many arguments mentioned in https://reviews.llvm.org/D110274#3025013.

Possible future extensions:
 * Instead of requiring the same type, bitcast/trunc/zext could be automatically inserted for some more flexibility.
 * If undef is added to the candidate set, "operands-skip"is able to produce any reduction that "operands" can do. Additional candidates might be zero and one, where the "reductive power" classification can prefer one over the other. If undefined behaviour should not be introduced, undef can be removed from the candidate set.

Reviewed By: aeubanks

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

This helper struct allows users of ComprehensiveBufferize to inject "post analysis" steps that are implemented after the analysis but before the bufferization.

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