LLVM blocks
Closed this issue · 7 comments
Functions should be able to specify code-block type as an LLVM block:
public func add(a: Int, b: Int) -> Int llvm {
define <returnType> <name>(<param>, <param>) {
ret i32 add ( i32 %0, %1 )
}
}
Instead of that, you could just do this:
public func add(a: Int, b: Int) -> Int llvm {
ret i32 add ( i32 %0, %1 )
}
Or better:
public func add(a: Int, b: Int) -> Int {
// do some important stuff
llvm {
ret i32 add ( i32 %0, %1 )
}
}
It's kinda redundant to be specifying the llvm define as well as the vsl function, since the compiler should be able to handle the function signature anyways.
oh :| yeah that is true (about the params). Personally I'm a fan of your former example, especially since with the latter we don't be able to run any checks on it:
public func doBork() {
var a = Goat()
llvm {
call void @otherFunction(Goat* %a) // ono now potential memory leak or bork.
}
}
Also we should have special syntax to pass a literal to the llvm
function, maybe we can use something like Haskell's Quasiquotation?
public func doBork() {
var a = Goat()
[|llvm|
call void @otherFunction(Goat* %a) // ono now potential memory leak or bork.
]
}
@ascii-only but how fixity mermomry peak
Um :| IDK maybe we shouldn't do it at all lol, instead provide bindings, instead:
public func doBork() {
var a = Goat()
with (llvm) {
call void @otherFunction, a // command chain, llvm.call.void(@otherFunction, a)
// llvm. prefixed as needed because of with llvm (maybe we need to use another keyword)
}
}
@somebody1234 we can do that for intrinsics but won't work for syntax, the point of embedded LLVM is to express what you can't with VSL
@vihanb Then yeah memory leak is big bork