Implement nback.llvm support for calling intrinsic functions about nballerina HOT 6 CLOSED

@jclark instead of two function types would it be okay if we

1. Update the Function output to handle the case where there is no body (just the function declaration) So it will correctly output with declare keyword instead of define. If I understand this correctly this behavior is not specific to just intrinsic but to any function (ref:https://llvm.org/docs/LangRef.html#functions) without a body.
2. Add a getIntrinsicDecleration function with signature public function getIntrinsicDecleration(IntrinsicID id, Type[] parameterTypes) returns Function in to the Module class (we need a reference to the module to add the function). Here IntrisicId will a type similar to BinaryInsn . Here I am suggesting a single function instead of one to get the id and another to get the declaration using that id because I feel at least at our current level two functions may be redundant and we can directly pass the id. This function will create the Function object for us setting the return types (and attributes in the future).

from nballerina.

For case 1, we still should distinguish function declaration from function definition. I don't like modelling a function declaration as a function definition with an empty body. I think we want

public type Function FunctionDefn|FunctionDecl;

and then use whichever of Function/FunctionDefn/FunctionDecl makes sense in each context.

For case 2, in LLVMGetIntrinsicDeclaration the parameter types are only for the overloaded case. I think we can more straightforwardly handle overloading by including the type in the intrinsic name. I would therefore suggest:

// No point in including "llvm." prefix here
type IntrinsicFunctionName "sadd.with.overflow.i64"|"ssub.with.overflow.i64"|"smul.with.overflow.i64";

public function getIntrinsicDeclaration(IntrinsicFunctionName name) returns FunctionDecl;

from nballerina.

For case 1, we still should distinguish function declaration from function definition. I don't like modelling a function declaration as a function definition with an empty body. I think we want

public type Function FunctionDefn|FunctionDecl;

and then use whichever of Function/FunctionDefn/FunctionDecl makes sense in each context.

For case 2, in LLVMGetIntrinsicDeclaration the parameter types are only for the overloaded case. I think we can more straightforwardly handle overloading by including the type in the intrinsic name. I would therefore suggest:

// No point in including "llvm." prefix here
type IntrinsicFunctionName "sadd.with.overflow.i64"|"ssub.with.overflow.i64"|"smul.with.overflow.i64";

public function getIntrinsicDeclaration(IntrinsicFunctionName name) returns FunctionDecl;

@jclark correct me if I am wrong but if we do like public type Function FunctionDefn|FunctionDecl; every time we need to access a method like output or genreg we have to check the base type (FunctionDefn or FunctionDecl) before calling those methods even if we implement the same method in both classes. So this will add those check to pretty much every where we use a Function. (We may also need to add two different methods in the module class for creating functions in the future if we are to allow users to add their own function definitions) Is that okay ?

from nballerina.

I'll write some code to show what I mean.

from nballerina.

I pushed some code: it's quite a nice demo of structural typing. I've intentionally made the code less object-oriented, and more Ballerina-ish.

I wanted to make isDefn be something whose value was "declare"|"define", but I couldn't think of a good name for the field.

from nballerina.

Thank you. I'll add the rest of the functionalities to that

from nballerina.