Float8E5M2FNUZ and Float8E4M3FNUZ have been added to APFloat in D141863.
This change adds these types as MLIR builtin types alongside Float8E5M2
and Float8E4M3FN (added in D133823 and D138075).
Reviewed By: krzysz00
Differential Revision: https://reviews.llvm.org/D143744
CMake supports CMAKE_CXX_COMPILER_LAUNCHER since CMake 3.4
so this custom CMake logic we had in LLVM can now be removed.
The only downside with this is that we can't set ccache
options from LLVM CMake, but it's arguable that this doesn't
belong in LLVM but should be done in a script calling the
build.
This was discussed in the forums here:
https://discourse.llvm.org/t/tips-for-incremental-building/67289/4?u=tobiashieta
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D143468
This commit adds a significant amount of visualizers attempting
to cover the majority of our visualization needs. It covers:
* Operations/OperationName/Ops/OpInterfaces
* Attributes/Types/Attr|TypeInterfaces/NamedAttribute
* Blocks/Regions
* Various range types (e.g. ValueRange/TypeRange)
* Values/BlockArguments/OpResults
This does require an NFC change to interfaces to rename
the concept field to avoid clash with the base class. It
also requires exposing a few method to the debugger
to help resolve information that is non-trivial to reconstruct.
These methods are re-exported using a debug_Blah naming
scheme to avoid messing with hot methods.
Note that this makes use of the new callback feature in lldb-16
(currently trunk) that allows for providing visualizers based on
a dynamic callback, instead of just the typename. It requires
a very new lldb, but allows for providing good default visualization
for all attributes/operations/types out of the box.
Differential Revision: https://reviews.llvm.org/D139602
This covers `SDot`, `SUDot`, and `UDot`. The `*AccSat` version will be
added in a follow-up revision.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D139242
This reverts commit ce82530cd0.
Undo accidental Vulkan/SPIR-V name changes.
Tested with `ninja check-mlir check-mlir-mlir-spirv-cpu-runner check-mlir-mlir-vulkan-runner`.
This reverts commit a2052b8794.
This commit renamed some Vulkan identifiers that shouldn't have been
renamed, e.g., `SPV_KHR_storage_buffer_storage_class`.
VSCode doesn't let our extension manage files >50mb. This commit
adds a proper diagnostic in this case, and also gives the user an option
to open as a temporary .mlir file instead.
Differential Revision: https://reviews.llvm.org/D133242
Use dedicated vendor op classes/categories. This is so that we can later
change the mnemonics of all vendor ops by changing the base class: `SPV_VendorOp`.
Issue: https://github.com/llvm/llvm-project/issues/56863
This commit adds support for interacting with a (valid) bytecode file in the same
way as .mlir. This allows editing, using all of the traditional LSP features, etc. but
still using bytecode as the on-disk serialization format. Loading a bytecode file this
way will fail if the bytecode is invalid, and saving will fail if the edited .mlir is invalid.
Differential Revision: https://reviews.llvm.org/D132970
Previously we are using IntegerAttr to back all SPIR-V enum
attributes. Therefore we all such attributes are showed like
IntegerAttr in IRs, which is barely readable and breaks
roundtripability of the IR. This commit changes to use
`EnumAttr` as the base directly so that we can have separate
attribute definitions and better IR printing.
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D131311
This commit updates all SPIR-V enum definitions to match the latest
specification (v1.6 revision 2). Along the way, fixed some issues
in `gen_spirv_dialect.py` and added a new script for refreshing
all op definitions for such cases.
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D131293
This attribute is technical debt from the early stages of MLIR, before
ElementsAttr was an interface and when it was more difficult for
dialects to define their own types of attributes. At present it isn't
used at all in tree (aside from being convenient for eliding other
ElementsAttr), and has had little to no evolution in the past three years.
Differential Revision: https://reviews.llvm.org/D129917
This is to improve the consistency within the SPIR-V dialect and to make op names a bit shorter.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D130194
This commit extends the `raise` statements on errors in user-provided
code with `from e` clauses that attach the original exception to the one
being raised. This allows to debug the root cause of the error more
easily.
Reviewed By: SaurabhJha
Differential Revision: https://reviews.llvm.org/D129762
Since version 0.9 we've:
* Bumped the language-client to `8.0.2-next.5` to fix various bugs/stability issues
* Fixed an issue with starting a language server for non-workspace files
This includes a fix for a code completion/document update bug where
code completion results were being requested before the document actually
updated.
Differential Revision: https://reviews.llvm.org/D129182
In the newer versions of the language client, this explicitly expects a
Promise<void> return type, otherwise it errors out.
Fixes#56297
Differential Revision: https://reviews.llvm.org/D129181
Some GDB versions require all prettyprinter classes to define to_string.
This commit adds these definitions.
Reviewed By: csigg
Differential Revision: https://reviews.llvm.org/D127969
These allow for displaying additional inline information,
such as the types of variables, names operands/results,
constraint/rewrite arguments, etc. This requires a bump in the
vscode extension to a newer version, as inlay hints are a new LSP feature.
Differential Revision: https://reviews.llvm.org/D126033
Since version 0.7 we've added:
* Initial language support for TableGen
* Tweaked syntax highlighting for PDLL
* Added a new command to view intermediate PDLL output
This commit adds a new PDLL specific LSP command, pdll.viewOutput, that
allows for viewing the intermediate outputs of a given PDLL file. The available
intermediate forms currently mirror those in mlir-pdll, namely: AST, MLIR, CPP.
This is extremely useful for a developer of PDLL, as it simplifies various testing,
and is also quite useful for users as they can easily view what is actually being
generated for their PDLL files.
This new command is added to the vscode client, and is available in the right
client context menu of PDLL files, or via the vscode command palette.
Differential Revision: https://reviews.llvm.org/D124783
This provides a format for externally specifying the include directories
for a source file. The format of the tablegen database is exactly the
same as that for PDLL, namely it includes the absolute source file name and
the set of include directories. The database format is shared to simplify
the infra, and also because the format itself is general enough to share. Even
if we desire to expand in the future to contain the actual compilation command,
nothing there is specific enough that we would need two different formats.
As with PDLL, support for generating the database is added to our mlir_tablegen
cmake command.
Differential Revision: https://reviews.llvm.org/D125441
This commit enables proper highlighting when inner statements are
outside of a constraint/pattern/etc. This shouldn't really happen in
actual code, but can happen in documentation (which uses the same
syntax grammar).
This follows the same general structure of the MLIR and PDLL language
servers. This commits adds the basic functionality for setting up the server,
and initially only supports providing diagnostics. Followon commits will
build out more comprehensive behavior.
Realistically this should eventually live in llvm/, but building in MLIR is an easier
initial step given that:
* All of the necessary LSP functionality is already here
* It allows for proving out useful language features (e.g. compilation databases)
without affecting wider scale tablegen users
* MLIR has a vscode extension that can immediately take advantage of it
Differential Revision: https://reviews.llvm.org/D125440
This was carry over from LLVM IR where the alias definition can
be ambiguous, but MLIR type aliases have no such problems.
Having the `type` keyword is superfluous and doesn't add anything.
This commit drops it, which also nicely aligns with the syntax for
attribute aliases (which doesn't have a keyword).
Differential Revision: https://reviews.llvm.org/D125501
The current grammar is really crusty, only supports a handful of
cases, and is also out-of-date after various refactorings. This commit
refactors the textmate grammar to handle significantly more cases,
and now provides proper coloring for a majority of cases (including
dialect attributes, operations, types, etc.)
Differential Revision: https://reviews.llvm.org/D125458
tree-sitter grammar file that tries to closely matches LangRef (it could use
some tweaking and cleanup, but kept fairly basic). Also updated LangRef in
places where found some issues while doing the nearly direct transcription.
This only adds a grammar file, not all the other parts (npm etc) that
accompanies it. Those I'll propose for separate repo like we do for vscode
extension.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D124352
The compilation database acts in a similar way to the compilation database
(compile_commands.json) used by clang-tidy, i.e. it provides additional
information about the compilation of project files to help the language
server. The main piece of information provided by the PDLL compilation
database in this commit is the set of include directories used when processing
the input .pdll file. This allows for the server to properly process .pdll files
that use includes anchored by the include directories set up in the build system.
The structure of the textual form of a compilation database is a yaml file
containing documents of the following form:
```
--- !FileInfo:
filepath: <string> - Absolute file path of the file.
includes: <string> - Semi-colon delimited list of include directories.
```
This commit also adds support to cmake for automatically generating
a `pdll_compile_commands.yml` file at the top-level of the build
directory.
Differential Revision: https://reviews.llvm.org/D124076
This avoids emitting errors in situations where the user doesn't have a server
setup, and doesn't mean to (e.g. when they merely want syntax highlighting).
Differential Revision: https://reviews.llvm.org/D123240
We currently proactively create language clients for every workspace folder,
and every language. This makes startup time more costly, and also emits errors
for missing language servers in contexts that the user currently isn't in. For example,
if a user opens a .mlir file we don't want to emit errors about .pdll files. We also don't
want to emit errors for missing servers in workspace folders that don't even utilize
MLIR.
This commit refactors client creation to lazy-load when a document that requires the
server is opened.
Differential Revision: https://reviews.llvm.org/D123184
In a previous commit we added proper support for separate configurations
per workspace folder, but that effectively broke support for processing out-of-workspace
files. Given how useful this is (e.g. when iterating on a test case in /tmp), this
commit refactors server creation to support this again. We support this case using
a "fallback" server that specifically handles files not within the workspace. This uses
the configuration settings for the current workspace itself (not the specific folder).
Differential Revision: https://reviews.llvm.org/D123183
We currently only launch one set of language clients when starting the extension,
but this has the unfortunate effect of applying the same settings to all workspace
folders. This commit adds support for multiple workspace folders by launching
a server for each folder in the workspace. This allows for having different servers
for different workspace folders, e.g. when there are multiple MLIR projects in
the same workspace.
Differential Revision: https://reviews.llvm.org/D122793
We currently require that server paths are full paths, which is
fairly inconvenient for a myriad of reasons. This commit
attempts to resolve a given server path with the current workspace.
This has a nice additional affect that we can now actually have
default server paths. This means that mlir-lsp-server and
mlir-pdll-lsp-server can be transparently picked up from
build directories (i.e. generally no need for upstream users to
configure the extension).
Fixes#54627
Differential Revision: https://reviews.llvm.org/D122792
In order to use the MLIR LSP server in Emacs, first the `mlir-lsp-client.el`
has to be loaded via elisp and then, one should call `lsp-mlir-setup` function
to setup the LSP client. After that simply calling the `lsp` function while
the `mlir-mode` is active with result in finding the language server (default
to `mlir-lsp-server`) via the `lsp-mlir-server-executable` customization variable
and connecting to it by the LSP library. Users who use MLIR's language server
library to create their own server can simply set the variable `lsp-mlir-server-executable`
to point to their own implementation executable.
Reviewed By: tschuett
Differential Revision: https://reviews.llvm.org/D123002
