Support for LLVM intrinsics

[bollu]

LLVM 4 introduced support for coroutines, and I would like access to these primitives.

From what I can tell, they're currently not exposed by llvm-hs. I'm cool with doing the dirty work and helping them be exposed if need be :) Can I have pointers?

[cocreature]

From what I can tell, they're currently not exposed by llvm-hs.

Yep, you’re right here.

I'm cool with doing the dirty work and helping them be exposed if need be

Great!

Can I have pointers?

So in general adding support for new instructions entails first adding them to the AST in llvm-hs-pure and then writing the necessary glue code in llvm-hs to convert between the Haskell AST and the C++ representation in LLVM itself. However, the coroutine instructions are special since they are intrinsics. I think it makes sense to handle all intrinsics the same way. I also don’t think it’s a good idea to add a separate constructor for each intrinsic as this would increase the number of constructors for Instr enormously making it hard to find what you are actually looking for.

So the question here boils down to how do we want to handle intrinsics in llvm-hs?

• I think they should be handled via the already existing call instruction. This is consistent with the way they look in the textual IR representation and it doesn’t need any new constructors for Instruction
• So what is the function argument passed to the call? We could either just specify it as a name via GlobalReference or we could add a new constructor Intrinsic to CallableOperand which is a giant sum type of the available intrinsics. The latter is better from the point of type safety but it does pose a new question: How do we create this sum type?
  • Writing it manually seems really annoying so I’d like to avoid that. However, this type lives in llvm-hs-pure which does not depend on the LLVM library so generating it via TH is not an option. The only solution I see here would be to write some script that reads Intrinsics.td and generates a Haskell file based on that. We can then bundle the generated Haskell file with llvm-hs-pure and thereby avoid the dependency on the LLVM library.
• Finally, we also need to write/generate the code converting between that AST and LLVM’s internal representation but I don’t see any fundamental problems on that side.

[cocreature]

So after discussing a bit with @bollu in IRC, we’ve come to the conclusion that the best solution is to write a parser for the Intrinsics.td file and generate the ADT representing the available intrinsics that way. Theoretically we could also write a C++ backend for LLVM’s own implementation of TableGen but it looks like that’s about as much work and if I can avoid writing C++ I’m all for it :)

I’ve created a new repo for the lexer/parser stuff at https://github.com/cocreature/llvm-tablegen (once it’s ready I’ll transfer it to the llvm-hs umbrella). The lexer already works so the next step is writing the parser and then we can figure out the generator.

[cocreature]

I‘ve looked into this and afaict there is actually nothing special about LLVM’s intrinsic that requires support from llvm-hs. You can just declare them like you declare any other function and it does the right thing™. If you need an example of how the declarations should look like, use moduleAST on some IR containing intrinsics.

It would be nice to have a more convenient way to generate these declarations but I’ll open a separate issue for that.