Wrap LLVM Intrinsics #89
Conversation
|
Instead of using |
|
Good catch. I'm also considering writing a tool that generates these definitions from |
|
trill-lang/TableGenSwift |
|
I'm hoping it won't come to reimplementing TableGen. e.g. Huon has a little tool in Rust that parses out the different definitions from the td files. |
|
I mean, I think it’d be fine to write a TableGen backend in C++ as a utility here. |
|
The first draft of the tool has been committed. Currently it dumps a huge file full of enums into the working directory of the tool. |
CodaFi
force-pushed
the
intr-alia
branch
9 times, most recently
from
3204f19 to
5c82ab8
Compare
Sources/LLVM/MetadataType.swift
Outdated
| @@ -7,6 +7,11 @@ import cllvm | |||
| public struct MetadataType: IRType { | |||
| internal let llvm: LLVMTypeRef | |||
|
|
|||
| internal init() { | |||
| // FIXME: This is just plain wrong. | |||
| self.llvm = PointerType(pointee: VoidType()).asLLVM() | |||
There was a problem hiding this comment.
For this, I'm thinking I generate a fake LLVMMDNode and try to grab its type.
Sources/LLVM/TokenType.swift
Outdated
| @@ -8,6 +8,11 @@ import cllvm | |||
| public struct TokenType: IRType { | |||
| internal let llvm: LLVMTypeRef | |||
|
|
|||
| internal init() { | |||
| // FIXME: This is just plain wrong. | |||
| self.llvm = PointerType(pointee: VoidType()).asLLVM() | |||
There was a problem hiding this comment.
I actually have no idea what to do about this. @llvm.coro.id is capable of producing Tokens that are consumed by the other @llvm.coro.* functions so we clearly need some way to initialize this properly, but there's nothing I can find in the C API that will do it.
|
Oh wow, of course I'm having trouble. Nobody took the time to properly expose the getters for these types. |
|
Submitted D38809 to track work getting these getters in. In the mean time I can |
|
#112 Disables these in the meantime and will allow me to remove these hacks. |
|
Does this mean you won't be able to use intrinsics including |
|
You absolutely can, you just have to run |
|
In the sense that it won't be automatic, yeah. |
|
Revision just got accepted. I think this can be parked until the next point release so this API is actually usable. |
|
We missed the boat for 5.0.1. Holding for 6.0 in the spring. |
|
Build will be restarted once #127 gets scheduled. |
CodaFi
force-pushed
the
intr-alia
branch
3 times, most recently
from
cf8bbcc to
e1b2032
Compare
CodaFi
force-pushed
the
intr-alia
branch
5 times, most recently
from
a007f09 to
431a5e6
Compare
The LLVM Intrinsics API is large, complex, platform-dependent, and in a constant state of flux. LLVM has chosen to manage this complexity with a set of TableGen definition files. Therefore, we must parse and interpret these files to provide a robust API. This commit introduces a new tool, 'intrinsics-gen', to be invoked from the top-level of the repository. The tool will read in any number of platform-dependent TableGen files and interpret them as a Swift file of enums with selectors. Each of these selectors either represents an intrinsic or a family of intrinsics that the framework is capable of resolving to one of LLVM's "proper intrinsic" selectors. The idea is that we do not ever ship this generated Swift file. Instead, users that wish to use this framework with the intrinsics will invoke 'intrinsics-gen' with the appropriate td file and SwiftPM will handle the rest. The API that will be committed is just the infrastructure necessary to support this. See the test suite for a concrete example of how to use this.
The infrastructure to generate
Calls is all here in this patch. However, the interface makes no guarantees of type safety, and LLVM overloads its intrinsics, so we have a real chance to provide just the subset of commented-out calls, do some type checks, and a little introspection to dispatch to the right intrinsic overload.Basically, what should the typesafe API look like, if any?