gpuopen-drivers / llvm-dialects Goto Github PK

It would simplify CMake scripts if a single llvm-dialects-tblgen invocation would generate both declarations and definitions for a given dialect.

When doing a standalone build of llvm-dialects, you need to specify the build directory of an llvm-project repo.
That llvm-project repo must be compatible with the llvm-dialects repo, which currently probably just means sufficiently recent.

However, it is not sufficent to check out the correct version of LLVM, but the LLVM build must also be up to date.
Otherwise, outdated autogenerated headers are used, resulting in weird errors.

Maybe there is a way to handle this in a better way?

I can think of the following, but there might be other options:

1. Use a standalone build dir for llvm-dialects that only depends on the LLVM source and also contains LLVM build artifacts.
2. Trigger an LLVM build as part of the llvm-dialects build. This could have unexpected sideeffects though. Maybe rebuild only some parts?

Currently if a dialect has two operations using the same intrinsic function name llvm-dialects will not raise an error. This should be caught as it's most likely unintentional.

def SomeOp : Op<ExampleDialect, "try.conflict", [WillReturn]> {
  let arguments = (ins value:$arg);
  let results = (outs I32:$result);
}

def IntrinsicConflictOp : Op<ExampleDialect, "try.conflict", [WillReturn]> {
  let arguments = (ins value:$arg);
  let results = (outs I32:$result);
}

llvm-dialects should report an error for such conflicts

If a dialect defines two ops, dialect.foo and dialect.foo.other, then a dialect.foo.other operation may be misinterpreted as a dialect.foo operation because, when name mangling for type overloads is in play, only a string prefix is compared.

Consider adding a marker that can unambiguously mark the end of the mnemonic, perhaps by unambiguously marking the beginning of any name mangling suffixes.

It would be awesome if llvm-dialects could use the tablegen definitions to generate a C-API automatically.
But how to do so is probably worth some discussion.

As an example this is the current IRBuilder API:

https://github.com/llvm/llvm-project/blob/7fe29e585723c8a90e798b3d852f2c54efb6f5dd/llvm/include/llvm-c/Core.h#L3742-L3753

But there are also delightful enums like: https://github.com/llvm/llvm-project/blob/7fe29e585723c8a90e798b3d852f2c54efb6f5dd/llvm/include/llvm-c/Core.h#L60

On my system, I configure and build llvm-dialects with system-wide LLVM headers and the CMake AddLLVM script. I use a standalone build outside of a LLVM tree.
While building dialects itself works, building check-llvm-dialects does not, as the includes are not propagated to this subtarget, so the compiler legitimately complains about missing LLVM includes.
When cloning dialects to a subfolder to llvm (tools), everything works.

Hi Nicolai. When building llpc with clang, I get:

imported/llvm-dialects/lib/Dialect/Dialect.cpp:66:17: warning: 'lock_guard' may not intend to support class template argument deduction [-Wctad-maybe-unsupported]

and the same at lines 76, 88, 98, 106.

My llvm-dialects is:

17aafec Add -no-memory-effects option

and my llvm-project is:

ca5b119ae6bf Merged main:42f957f55d3b into amd-gfx:8516ad1b9031

(from the GPUOpen llvm-project).

Migrating from an older commit that had AnyType, I get a nullptr dereference with the following dialect:

include "llvm-dialects/Dialect/Dialect.td"

def MyDialect : Dialect {
  let name = "my";
  let cppNamespace = "my";
}

class MyOp<string mnemonic_, list<Trait> traits_ = []>
    : Op<MyDialect, mnemonic_, traits_ # [NoUnwind]>;

def MyReturnOp : MyOp<"return", [WillReturn]> {
  let arguments = (ins);
  let results = (outs type:$result); // <-- The error is here, it should be (outs value:$result)

  let defaultBuilderHasExplicitResultType = true;

  let summary = "returns a value";
}

Creating a custom type without type and/or integer arguments currently generates code that does not compile.
All of the following types fail:

def MyTokenType0 : DialectType<MyDialect, "token"> {
  let typeArguments = (args);

  let defaultGetterHasExplicitContextArgument = true;
}

def MyTokenType1 : DialectType<MyDialect, "token"> {
  let typeArguments = (args type:$dummy);

  let defaultGetterHasExplicitContextArgument = true;
}

def MyTokenType2 : DialectType<MyDialect, "token"> {
  let typeArguments = (args AttrI32:$dummy);

  let defaultGetterHasExplicitContextArgument = true;
}

MyDialect.cpp.inc:78:19: warning: zero size arrays are an extension [-Wzero-length-array]
    unsigned ints[0] = {
                  ^
MyDialect.cpp.inc:82:96: error: no viable conversion from 'unsigned int[0]' to 'ArrayRef<unsigned int>'
      auto *type = ::llvm::cast<MyTokenType>(::llvm::TargetExtType::get(ctx, s_name, types, ints));

I have been eyeing llvm-dialects from afar. I would like to use it to "formailize" Julia's LLVM dialect which is a set of pseudo-intrinsics and usage of custom address-spaces.

Julia doesn't target LLVM ToT, but rather takes the latest stable LLVM release and uses that as a basis for a Julia release. Currently 1.9 is released and 1.10 is in beta.

1.6 -> LLVM 11
1.7 -> LLVM 12
1.8 -> LLVM 13
1.9 -> LLVM 14
1.10 -> LLVM 15
1.11 -> ??? (Probably LLVM 16; maybe LLVM 17 if that's easy)

We pick an LLVM release towards the end/middle of our own development phase and then have a release stabilization process.

So I was trying to figure out the other day which commit I would need to use to try out llvm-dialects on LLVM 15.

I don't expect a change in the development practices here, but it would be nice to document which commit roughly corresponds to which LLVM release (even better to tag a commit that is known to work with a LLVM release)