How to return optional types from runtime

[ruvi-d]

Primer

This is related to runtime functions like map loads that might return nill. e.g.

map<int> marks = {sam: 50, jon: 60};
int? val = marks["jake"];

corresponding BIR snippet

%1(LOCAL) map<int>;
%8(LOCAL) int | ();
%10(TEMP) string;

%1 = NewMap %2;
%10 = ConstLoad jake;
%8 = %1[%10];

Also note that for Any type and Union type variables we use a LLVM defined structure to hold it's value. This structure type is labeled as struct.smtPtr and it's format is as follows:

struct smtPtr {
  int32_t type_string_table_index;
  void * value;
}

• type_string_table_index allows us to figure out the value literal's type via mangled type string table look up
• value is a pointer to the value literal (usually a boxed value)

Options 1

Runtime's map_load method will return a success value indicating whether the key was found. The actual value will be returned via an output param. Example for map type load instruction

#[no_mangle]
pub extern "C" fn map_load_int(ptr: *mut BalMapInt, key: *mut BString, output_val: *mut i32) -> bool {
    // Load BalMap from pointer
    assert!(!ptr.is_null());
    let bal_map = unsafe { &mut *ptr };

    // Load Key C string
    assert!(!key.is_null());
    let key_str = unsafe { (*key).value };

    // Output param
    assert!(!output_val.is_null());
    match bal_map.get(key_str) {
        Some(val) => {
            unsafe { *output_val = val.clone() };
            true
        }
        None => false,
    }
}

On the codegen side we need to branch depending on the return value. However generating a branch instruction from the codegen side is rather complicated currently as MapLoadInstruction is modeled as a non-terminating instruction. A sample code for map type load instruction would look something like below.

void MapLoadInsn::translate(LLVMModuleRef &modRef) {
    const auto &funcObj = getFunctionRef();
    auto builder = funcObj.getLLVMBuilder();
    
    LLVMValueRef lhs = funcObj.getLLVMLocalOrGlobalVar(getLhsOperand());
    LLVMValueRef outParam = LLVMBuildAlloca(builder, LLVMInt32Type(), "_out_param");
    LLVMValueRef params[] = {funcObj.createTempVariable(rhsOp), funcObj.createTempVariable(keyOp), outParam};
    
    [[maybe_unused]] LLVMValueRef retVal = LLVMBuildCall(builder, getMapLoadDeclaration(modRef), params, 3, "");

    // if retVal is true
    getFunctionMutableRef().addValueToSmartStruct(modRef, outParam, Type(TYPE_TAG_INT, ""), lhs);
    
    // otherwise generate this code
    // getFunctionMutableRef().addValueToSmartStruct(modRef, getPackageRef().getGlobalNilVar(), Type(TYPE_TAG_NIL, ""), lhs);
}

Here we would need to check retVal and branch. This means that we need to split the current basic block and move around instructions and patch the basic block connections. That can't be done in this instruction's translate function scope and would require us to go up a few levels to its parent Function class translate function scope.

The TypeCast Instruction also has a similar requirement where it needs to call the runtime is_same_type function and abort if a casting can't be done. It solves this problem by adding a temp branch instruction:
https://github.com/ballerina-platform/nballerina/blob/master/compiler/codegen/TypeCastInsn.cpp#L79
and then later inserting the call to abort function and doing the basic block patching as a separate pass (step) that is done after doing codegen for all the instructions
https://github.com/ballerina-platform/nballerina/blob/master/compiler/codegen/Function.cpp#L220

We can't do the same for map load here because, we need the BIR class information to generate the code that goes to the two branches (i.e. load the correct values to LHS's smtPtr).

Summary:

• Naively the obvious choice
• However, due to our current class model and codegen sequence, it is not trivial to do (unless someone has an idea?)

Options 2

Pass the int? val to the runtime as part of the map_load instruction and have the runtime load the correct values to it. Example incomplete code just to illustrate the point.

#[repr(C)]
pub struct smtPtr {
    str_table_offset: i32,
    val: *mut c_void,
}

#[no_mangle]
pub extern "C" fn map_load_int(ptr: *mut BalMapInt, key: *mut BString, output_val: *mut smtPtr) -> bool {
    // Load BalMap from pointer
    assert!(!ptr.is_null());
    let bal_map = unsafe { &mut *ptr };

    // Load Key C string
    assert!(!key.is_null());
    let key_str = unsafe { (*key).value };

    // Output param
    assert!(!output_val.is_null());
    let output_val = unsafe { &mut *output_val };

    match bal_map.get(key_str) {
        Some(val) => {
            output_val.val = Box::into_raw(Box::new(val.clone())) as *mut c_void;
            // TODO set string table offset to type
            true
        }
        None => {
            output_val.val = Box::into_raw(Box::new(0)) as *mut c_void;
            // TODO set string table offset to type
            false
        }
    }
}

This can't be completed currently because the mangled type string table is managed on the LLVM codegen side. Thus it would be have to be moved to the runtime.
This brings us back the larger discussion that we previously shelved about moving the Any and Union types to the Rust side. Currently there is no obvious advantage with the LLVM codegen handling the smtPtr as we need to pass them to the runtime anyway to operate on them. If the LLVM codegen was able to do things like do is_same_type with the smtPtr without having to pass the references to the Runtime, it would make sense to stick with the current implementation. Since it is not the case, the option discussed here (to have the runtime directly populate the optional map load value), makes it worthwhile to reconsider.

Summary:

• Simplify the LLVM codegen logic and move most of the logic to the Rust side
• Requires moving the Any and Union type allocation to the runtime (similar how strings, arrays and maps are currently handled as opaque Rust pointer types)

[ruvi-d]

@ayonam , @manuranga , @ramakotareddy , @shubhamnarlawar and @KavinduZoysa

[KavinduZoysa]

@ruvi-d, under the 2nd option, I cannot understand the reason you suggest to move allocating smtPrt in rust side. Why can't we create smtPrt on llvm side and pass the reference to rust side and update it on rust side?

[ruvi-d]

Why can't we create smtPrt on llvm side and pass the reference to rust side and update it on rust side?

I was thinking because of the string table offset value in smtPrt. We can't add the type string from the Rust side right?

[KavinduZoysa]

We can generate the mangled type name from the rust side and update the smtPtr in the rust side. IMO, rest of the things can be done in llvm side

[ruvi-d]

We can generate the mangled type name from the rust side and update the smtPtr in the rust side. IMO, rest of the things can be done in llvm side

If so, then what's the point of having the rest on the llvm side? :-)

Also, it's not just a matter of generating the mangled name in the Rust side. Currently we are putting it in a string table and putting only the offset in the smtPtr. So we either have to move the string table to Rust side, or just skip the string table and keep the full mangled string in smtPtr (less efficient ofcourse).

[KavinduZoysa]

Yes, I got the point, Then we have to move it to the rust side.

[ruvi-d]

Since we want to minimize the Rust usage for non std lib components; I suppose option 1 would be the preference.

We can try @manuranga's suggesting to create a pass after BIR parsing to identify map loading instructions and inject new branching instructions and basic blocks.

[ruvi-d]

Does anyone have any objections?

[manuranga]

I think our direction is to make the runtime be tightly coupled with the llvm genarated code. That means the return value shouldn't be converted at llvm side. In that case do we still need a cconditional in llvm side?

[ruvi-d]

@manuranga : "converted at llvm side" as in boxed into the current implementation's fat pointer right? If we are avoid that then, yes, no need for conditional in llvm side. But then we would have to go down option 2 right?
Maybe I didn't understand your suggestion.

[ruvi-d]

Option 1 is now easily viable (as of #282 ) and will be considered as the idiomatic approach