[CodeGen] Rename MVT::iPTRAny to MVT::pAny

Whilst in upstream LLVM iPTRAny is only ever an integer, essentially an
alias for iPTR, this is not true in CHERI LLVM, where it gets used to
mean "iPTR or

[CodeGen] Rename MVT::iPTRAny to MVT::pAny

Whilst in upstream LLVM iPTRAny is only ever an integer, essentially an
alias for iPTR, this is not true in CHERI LLVM, where it gets used to
mean "iPTR or cPTR", i.e. either an integer address or a capability
(with cPTR and cN being the capability equivalents of iPTR and iN).
Moreover, iPTRAny is already not itself regarded as an integer (calling
isInteger() will give false), so the "i" prefix is misleading, and it
stands out as different from all the other xAny that have a single
letter prefix denoting their type.

Thus, rename it to pAny, reflecting that it is an overloaded pointer
type, which could end up being specialised to an integer type, but does
not have to be.

This has been verified to have no effect on the generated files for LLVM
itself or any in-tree target beyond the replacement of the identifier
iPTRAny with pAny in GenVT.inc.

Reviewers: arsenm

Reviewed By: arsenm

Pull Request: https://github.com/llvm/llvm-project/pull/113733

show more ...

[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841)

Eliminate `llvm::` namespace qualifier for commonly used types in MLIR
TableGen backends to reduce code clutter.

[llvm] Move CodeGenTypes library to its own directory (#79444)

Finally addresses https://reviews.llvm.org/D148769#4311232 :)

No behavior change.

[mlir] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[mlir] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[llvm][tblgen] Add `Source Filename` for `emitSourceFileHeader` (#65744)

I think this is very helpful for reading generated `.inc` files.

[mlir][flang] Convert TBAA metadata to an attribute representation

The current representation of TBAA is the very last in-tree user of the `llvm.metadata` operation.
Using ops to model metadata has

[mlir][flang] Convert TBAA metadata to an attribute representation

The current representation of TBAA is the very last in-tree user of the `llvm.metadata` operation.
Using ops to model metadata has a few disadvantages:
* Building a graph has to be done through some weakly typed indirection mechanism such as `SymbolRefAttr`
* Creating the metadata has to be done through a builder within a metadata op.
* It is not multithreading safe as operation insertion into the same block is not thread-safe

This patch therefore converts TBAA metadata into an attribute representation, in a similar manner as it has been done for alias groups and access groups in previous patches.

This additionally has the large benefit of giving us more "correctness by construction" as it makes things like cycles in a TBAA graph, or references to an incorrectly typed metadata node impossible.

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

show more ...

[mlir][LLVM] Convert access group metadata to using attributes instead of ops

Using MLIR attributes instead of metadata has many advantages:
* No indirection: Attributes can simply refer to each oth

[mlir][LLVM] Convert access group metadata to using attributes instead of ops

Using MLIR attributes instead of metadata has many advantages:
* No indirection: Attributes can simply refer to each other seemlessly without having to use the indirection of `SymbolRefAttr`. This also gives us correctness by construction in a lot of places as well
* Multithreading safe: The Attribute infrastructure gives us thread-safety for free. Creating operations and inserting them into a block is not thread-safe. This is a major use case for e.g. the inliner in MLIR which runs in parallel
* Easier to create: There is no need for a builder or a metadata region

This patch therefore does exactly that. It leverages the new distinct attributes to create distinct access groups in a deterministic and threadsafe manner.

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

show more ...

[mlir][LLVM] Convert alias metadata to using attributes instead of ops

Using MLIR attributes instead of metadata has many advantages:
* No indirection: Attributes can simply refer to each other seem

[mlir][LLVM] Convert alias metadata to using attributes instead of ops

Using MLIR attributes instead of metadata has many advantages:
* No indirection: Attributes can simply refer to each other seemlessly without having to use the indirection of `SymbolRefAttr`. This also gives us correctness by construction in a lot of places as well
* Multithreading save: The Attribute infrastructure gives us thread-safety for free. Creating operations and inserting them into a block is not thread-safe. This is a major use case for e.g. the inliner in MLIR which runs in parallel
* Easier to create: There is no need for a builder or a metadata region

This patch therefore does exactly that. It leverages the new distinct attributes to create distinct alias domains and scopes in a deterministic and threadsafe manner.

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

show more ...

Try to fix CodeGenTypes issues in mlir

[mlir][llvm] Add AliasAnalysis and AccessGroup interfaces to intrinsics.

This revision updates the memcpy, memove, and memset intrinsics to
implement the AliasAnalysis and AccessGroup interfaces. Th

[mlir][llvm] Add AliasAnalysis and AccessGroup interfaces to intrinsics.

This revision updates the memcpy, memove, and memset intrinsics to
implement the AliasAnalysis and AccessGroup interfaces. The changes
will enable the import and export of alias scope, tbaa, and
access group metadata attached to these intrinsics. It also
renames the requiresAliasScope flag to requiresAliasAnalysis since
the intrinsics also support tbaa and not only access scope metadata.

The revision still maintains the string based attribute lookup
in the translation from MLIR to LLVMIR. Using the interfaces
instead of the string based lookup is left to a followup revision.

Depends on D144851

Reviewed By: Dinistro

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

show more ...

Introduce a ConditionallySpeculatable op interface

This patch takes the first step towards a more principled modeling of undefined behavior in MLIR as discussed in the following discourse threads:

Introduce a ConditionallySpeculatable op interface

This patch takes the first step towards a more principled modeling of undefined behavior in MLIR as discussed in the following discourse threads:

1. https://discourse.llvm.org/t/semantics-modeling-undefined-behavior-and-side-effects/4812
2. https://discourse.llvm.org/t/rfc-mark-tensor-dim-and-memref-dim-as-side-effecting/65729

This patch in particular does the following:

1. Introduces a ConditionallySpeculatable OpInterface that dynamically determines whether an Operation can be speculated.
2. Re-defines `NoSideEffect` to allow undefined behavior, making it necessary but not sufficient for speculation. Also renames it to `NoMemoryEffect`.
3. Makes LICM respect the above semantics.
4. Changes all ops tagged with `NoSideEffect` today to additionally implement ConditionallySpeculatable and mark themselves as always speculatable. This combined trait is named `Pure`. This makes this change NFC.

For out of tree dialects:

1. Replace `NoSideEffect` with `Pure` if the operation does not have any memory effects, undefined behavior or infinite loops.
2. Replace `NoSideEffect` with `NoSideEffect` otherwise.

The next steps in this process are (I'm proposing to do these in upcoming patches):

1. Update operations like `tensor.dim`, `memref.dim`, `scf.for`, `affine.for` to implement a correct hook for `ConditionallySpeculatable`. I'm also happy to update ops in other dialects if the respective dialect owners would like to and can give me some pointers.
2. Update other passes that speculate operations to consult `ConditionallySpeculatable` in addition to `NoMemoryEffect`. I could not find any other than LICM on a quick skim, but I could have missed some.
3. Add some documentation / FAQs detailing the differences between side effects, undefined behavior, speculatabilty.

Reviewed By: rriddle, mehdi_amini

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

show more ...

Apply clang-tidy fixes for performance-for-range-copy to MLIR (NFC)

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

Fix clang-tidy issues in mlir/ (NFC)

Reviewed By: ftynse

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

Support alias.scope and noalias metadata lowering on intrinsics.

Builds on https://reviews.llvm.org/D107870 to support annotating intrinsics with alias.scope and noalias metadata.

Reviewed By: arpi

Support alias.scope and noalias metadata lowering on intrinsics.

Builds on https://reviews.llvm.org/D107870 to support annotating intrinsics with alias.scope and noalias metadata.

Reviewed By: arpith-jacob, ftynse

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

show more ...

[mlir] Add an AccessGroup attribute to load/store LLVM dialect ops and generate the access_group LLVM metadata.

This also includes LLVM dialect ops created from intrinsics.

Reviewed By: ftynse

Dif

[mlir] Add an AccessGroup attribute to load/store LLVM dialect ops and generate the access_group LLVM metadata.

This also includes LLVM dialect ops created from intrinsics.

Reviewed By: ftynse

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

show more ...

Fix side-effect detection in LLVMIRIntrinsicGen.

Previously it reported an op had side-effects iff it declared that it
didn't have any side-effects. This had the undesirable result that
canonicaliz

Fix side-effect detection in LLVMIRIntrinsicGen.

Previously it reported an op had side-effects iff it declared that it
didn't have any side-effects. This had the undesirable result that
canonicalization would always delete any intrinsic calls that did memory
stores and returned void.

Reviewed By: ftynse, mehdi_amini

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

show more ...

[mlir][TableGen] Support intrinsics with multiple returns and overloaded operands.

For intrinsics with multiple returns where one or more operands are overloaded, the overloaded type is inferred fro

[mlir][TableGen] Support intrinsics with multiple returns and overloaded operands.

For intrinsics with multiple returns where one or more operands are overloaded, the overloaded type is inferred from the corresponding field of the resulting struct, instead of accessing the result directly.

As such, the hasResult parameter of LLVM_IntrOpBase (and derived classes) is replaced with numResults. TableGen for intrinsics also updated to populate this field with the total number of results.

Reviewed By: ftynse

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

show more ...

[MLIR] Rename SideEffects.td -> SideEffectInterfaces.td

This normalize the name of the tablegen file with the name of the generated
files (SideEffectInterfaces.h.inc) and the other Interface tablege

[MLIR] Rename SideEffects.td -> SideEffectInterfaces.td

This normalize the name of the tablegen file with the name of the generated
files (SideEffectInterfaces.h.inc) and the other Interface tablegen files,
which all end in Interface(s).td

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

show more ...

[mlir][NFC] Remove the STLExtras.h header file now that it has been merged into LLVM.

Now that no more utilities exist within, this file can be deleted.

Differential Revision: https://reviews.llvm.

[mlir][NFC] Remove the STLExtras.h header file now that it has been merged into LLVM.

Now that no more utilities exist within, this file can be deleted.

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

show more ...

[llvm][STLExtras] Move the algorithm `interleave*` methods from MLIR to LLVM

These have proved incredibly useful for interleaving values between a range w.r.t to streams. After this revision, the ml

[llvm][STLExtras] Move the algorithm `interleave*` methods from MLIR to LLVM

These have proved incredibly useful for interleaving values between a range w.r.t to streams. After this revision, the mlir/Support/STLExtras.h is empty. A followup revision will remove it from the tree.

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

show more ...

[mlir][SideEffects][NFC] Move the .td definitions for NoSideEffect/RecursiveSideEffect to SideEffects.td

This matches the location of these traits within the source files.

Differential Revision: ht

[mlir][SideEffects][NFC] Move the .td definitions for NoSideEffect/RecursiveSideEffect to SideEffects.td

This matches the location of these traits within the source files.

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

show more ...

[mlir] Intrinsics generator: use TableGen-defined builder function

Originally, intrinsics generator for the LLVM dialect has been producing
customized code fragments for the translation of MLIR oper

[mlir] Intrinsics generator: use TableGen-defined builder function

Originally, intrinsics generator for the LLVM dialect has been producing
customized code fragments for the translation of MLIR operations to LLVM IR
intrinsics. LLVM dialect ODS now provides a generalized version of the
translation code, parameterizable with the properties of the operation.
Generate ODS that uses this version of the translation code instead of
generating a new version of it for each intrinsic.

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

show more ...

Mass update the MLIR license header to mention "Part of the LLVM project"

This is an artifact from merging MLIR into LLVM, the file headers are
now aligned with the rest of the project.

[mlir] Use all_of instead of a manual loop in IntrinsicGen. NFC

This was suggested in post-commit review of D72926.

[mlir] Add option to use custom base class for dialect in LLVMIRIntrinsicGen.

Summary:
LLVMIRIntrinsicGen is using LLVM_Op as the base class for intrinsics.
This works for LLVM intrinsics in the LLV

[mlir] Add option to use custom base class for dialect in LLVMIRIntrinsicGen.

Summary:
LLVMIRIntrinsicGen is using LLVM_Op as the base class for intrinsics.
This works for LLVM intrinsics in the LLVM Dialect, but when we are
trying to convert custom intrinsics that originate from a custom
LLVM dialect (like NVVM or ROCDL) these usually have a different
"cppNamespace" that needs to be applied to these dialect.

These dialect specific characteristics (like "cppNamespace")
are typically organized by creating a custom op (like NVVM_Op or
ROCDL_Op) that passes the correct dialect to the LLVM_OpBase class.

It seems natural to allow LLVMIRIntrinsicGen to take that into
consideration when generating the conversion code from one of these
dialect to a set of target specific intrinsics.

Reviewers: rriddle, andydavis1, antiagainst, nicolasvasilache, ftynse

Subscribers: jdoerfert, mehdi_amini, jpienaar, burmako, shauheen, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits

Tags: #llvm

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

show more ...