[mlir][NFC] Move several small methods from .cpp to .h to allow more aggressive inlining

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

[mlir] Add better support for f80 and f128

Add builtin f80 and f128 following @schweitz proposition
https://llvm.discourse.group/t/rfc-adding-better-support-for-higher-precision-floating-point/2526/

[mlir] Add better support for f80 and f128

Add builtin f80 and f128 following @schweitz proposition
https://llvm.discourse.group/t/rfc-adding-better-support-for-higher-precision-floating-point/2526/5

Reviewed By: ftynse, rriddle

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

show more ...

[mlir][Types][NFC] Move all of the builtin Type classes to BuiltinTypes.h

This is part of a larger refactoring the better congregates the builtin structures under the BuiltinDialect. This also remov

[mlir][Types][NFC] Move all of the builtin Type classes to BuiltinTypes.h

This is part of a larger refactoring the better congregates the builtin structures under the BuiltinDialect. This also removes the problematic "standard" naming that clashes with the "standard" dialect, which is not defined within IR/. A temporary forward is placed in StandardTypes.h to allow time for downstream users to replaced references.

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

show more ...

[MLIR] Move eraseArguments and eraseResults to FunctionLike

Previously, they were only defined for `FuncOp`.

To support this, `FunctionLike` needs a way to get an updated type
from the concrete ope

[MLIR] Move eraseArguments and eraseResults to FunctionLike

Previously, they were only defined for `FuncOp`.

To support this, `FunctionLike` needs a way to get an updated type
from the concrete operation. This adds a new hook for that purpose,
called `getTypeWithoutArgsAndResults`.

For now, `FunctionLike` continues to assume the type is
`FunctionType`, and concrete operations that use another type can hide
the `getType`, `setType`, and `getTypeWithoutArgsAndResults` methods.

Reviewed By: rriddle

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

show more ...

[mlir] Remove the use of "kinds" from Attributes and Types

This greatly simplifies a large portion of the underlying infrastructure, allows for lookups of singleton classes to be much more efficient

[mlir] Remove the use of "kinds" from Attributes and Types

This greatly simplifies a large portion of the underlying infrastructure, allows for lookups of singleton classes to be much more efficient and always thread-safe(no locking). As a result of this, the dialect symbol registry has been removed as it is no longer necessary.

For users broken by this change, an alert was sent out(https://llvm.discourse.group/t/removing-kinds-from-attributes-and-types) that helps prevent a majority of the breakage surface area. All that should be necessary, if the advice in that alert was followed, is removing the kind passed to the ::get methods.

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

show more ...

[mlir][Types] Remove the subclass data from Type

Subclass data is useful when a certain amount of memory is allocated, but not all of it is used. In the case of Type, that hasn't been the case for a

[mlir][Types] Remove the subclass data from Type

Subclass data is useful when a certain amount of memory is allocated, but not all of it is used. In the case of Type, that hasn't been the case for a while and the subclass is just taking up a full `unsigned`. Removing this frees up ~8 bytes for almost every type instance.

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

show more ...

[MLIR] Change FunctionType::get() and TupleType::get() to use TypeRange

- Moved TypeRange into its own header/cpp file, and add hashing support.
- Change FunctionType::get() and TupleType::get() to

[MLIR] Change FunctionType::get() and TupleType::get() to use TypeRange

- Moved TypeRange into its own header/cpp file, and add hashing support.
- Change FunctionType::get() and TupleType::get() to use TypeRange

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

show more ...

[mlir] Add support for defining Traits and Interfaces on Attributes/Types.

This revisions add mechanisms to Attribute/Type for attaching traits and interfaces. The mechanisms are modeled 1-1 after t

[mlir] Add support for defining Traits and Interfaces on Attributes/Types.

This revisions add mechanisms to Attribute/Type for attaching traits and interfaces. The mechanisms are modeled 1-1 after those for operations to keep the system consistent. AttrBase and TypeBase now accepts a trailing list of `Trait` types that will be attached to the object. These traits should inherit from AttributeTrait::TraitBase and TypeTrait::TraitBase respectively as necessary. A followup commit will refactor the interface gen mechanisms in ODS to support Attribute/Type interface generation and add tests for the mechanisms.

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

show more ...

[mlir] Refactor the structure of the 'verifyConstructionInvariants' methods.

Summary:
The current structure suffers from several problems, but the main one is that a construction failure is impossib

[mlir] Refactor the structure of the 'verifyConstructionInvariants' methods.

Summary:
The current structure suffers from several problems, but the main one is that a construction failure is impossible to debug when using the 'get' methods. This is because we only optionally emit errors, so there is no context given to the user about the problem. This revision restructures this so that errors are always emitted, and the 'get' methods simply pass in an UnknownLoc to emit to. This allows for removing usages of the more constrained "emitOptionalLoc", as well as removing the need for the context parameter.

Fixes [PR#44964](https://bugs.llvm.org/show_bug.cgi?id=44964)

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

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.

Adjust License.txt file to use the LLVM license

PiperOrigin-RevId: 286906740

Add emitOptional(Error|Warning|Remark) functions to simplify emission with an optional location.

In some situations a diagnostic may optionally be emitted by the presence of a location, e.g. attribu

Add emitOptional(Error|Warning|Remark) functions to simplify emission with an optional location.

In some situations a diagnostic may optionally be emitted by the presence of a location, e.g. attribute and type verification. These situations currently require extra 'if(loc) emitError(...); return failure()' wrappers that make verification clunky. These new overloads take an optional location and a list of arguments to the diagnostic, and return a LogicalResult. We take the arguments directly and return LogicalResult instead of returning InFlightDiagnostic because we cannot create a valid diagnostic with a null location. This creates an awkward situation where a user may try to treat the, potentially null, diagnostic as a valid one and encounter crashes when attaching notes/etc. Below is an example of how these methods simplify some existing usages:

Before:

if (loc)
emitError(*loc, "this is my diagnostic with argument: ") << 5;
return failure();

After:

return emitOptionalError(loc, "this is my diagnostic with argument: ", 5);

PiperOrigin-RevId: 283853599

show more ...

NFC: Add header blocks to improve readability.
PiperOrigin-RevId: 263951251

Add support for SPIR-V Struct Types. Current support is limited to
supporting only Offset decorations

PiperOrigin-RevId: 256216704

Move the emitError/Warning/Remark utility methods out of MLIRContext and into the mlir namespace.

Now that Locations are attributes, they have direct access to the MLIR context. This allows for simp

Move the emitError/Warning/Remark utility methods out of MLIRContext and into the mlir namespace.

Now that Locations are attributes, they have direct access to the MLIR context. This allows for simplifying error emission by removing unnecessary context lookups.

PiperOrigin-RevId: 255112791

show more ...

Update Attribute::getDialect/Type::getDialect to return a non-const dialect reference.

--

PiperOrigin-RevId: 249467245

Remove some extraneous const qualifiers on Type, and 0b1 -> 1 in tblgen files. (NFC)

--

PiperOrigin-RevId: 248332674

Add an AttrBase class to simplify defining derived Attributes. This class serves the same purpose as TypeBase, and thus the duplicated functionality has been split into a new support class 'StorageUs

Add an AttrBase class to simplify defining derived Attributes. This class serves the same purpose as TypeBase, and thus the duplicated functionality has been split into a new support class 'StorageUserBase'.

--

PiperOrigin-RevId: 247358373

show more ...

Make the Twine parameter of the current diagnostic emit functions optional. This allows for the ability to exclusively use the new diagnostic interface without breaking all of the existing usages. Se

Make the Twine parameter of the current diagnostic emit functions optional. This allows for the ability to exclusively use the new diagnostic interface without breaking all of the existing usages. Several diagnostics emitted in lib/IR have been updated to make use of this functionality.

--

PiperOrigin-RevId: 246546044

show more ...

Introduce a new API for emitting diagnostics with Diagnostic and InFlightDiagnostic.

The Diagnostic class contains all of the information necessary to report a diagnostic to the DiagnosticEngine

Introduce a new API for emitting diagnostics with Diagnostic and InFlightDiagnostic.

The Diagnostic class contains all of the information necessary to report a diagnostic to the DiagnosticEngine. It should generally not be constructed directly, and instead used transitively via InFlightDiagnostic. A diagnostic is currently comprised of several different elements:
* A severity level.
* A source Location.
* A list of DiagnosticArguments that help compose and comprise the output message.
* A DiagnosticArgument represents any value that may be part of the diagnostic, e.g. string, integer, Type, Attribute, etc.
* Arguments can be added to the diagnostic via the stream(<<) operator.
* (In a future cl) A list of attached notes.
* These are in the form of other diagnostics that provide supplemental information to the main diagnostic, but do not have context on their own.

The InFlightDiagnostic class represents an RAII wrapper around a Diagnostic that is set to be reported with the diagnostic engine. This allows for the user to modify a diagnostic that is inflight. The internally wrapped diagnostic can be reported directly or automatically upon destruction.

These classes allow for more natural composition of diagnostics by removing the restriction that the message of a diagnostic is comprised of a single Twine. They should also allow for nice incremental improvements to the diagnostics experience in the future, e.g. formatv style diagnostics.

Simple Example:

emitError(loc, "integer bitwidth is limited to " + Twine(IntegerType::kMaxWidth) + " bits");
emitError(loc) << "integer bitwidth is limited to " << IntegerType::kMaxWidth << " bits";

--

PiperOrigin-RevId: 246526439

show more ...

Rename UnknownType to OpaqueType (NFC)

This came up in a review of the tutorial, it was suggested that "opaque" is more
descriptive than "unknown" here.

--

PiperOrigin-RevId: 241832927

Update TypeBase::verifyConstructionInvariants to use a LogicalResult return instead of bool.

--

PiperOrigin-RevId: 241045568

Update some of the derived type classes to use getImpl instead of a static_cast.

PiperOrigin-RevId: 240084937

Introduce a TypeID class to provide unique identifiers for derived type classes. This removes the need for derived types to define a static typeID field.

PiperOrigin-RevId: 237482890

Validate the names of attribute, dialect, and functions during verification. This essentially enforces the parsing rules upon their names.

PiperOrigin-RevId: 235818842