Interrogate PointerValue in symbol-table to determine type for builder.build_load call?

[1414C]

llvm-17; inkwell 0.5.0; cargo/rustc 1.80.0;Debian 6.1.99-1 (2024-07-15) x86_64 GNU/Linux

While chipping away at my inkwell side-project I was thinking to use a symbol-table as shown in the following code snippet to track variables. The idea was that a hash-map keyed by variable name and holding a PointerValue would be an easy way to abstract the symbol values. This worked well for variable creation and initial assignment but I am running into walls when trying to come up with a good way to determine the BasicEnumType of the BasicEnumValue that the PointerValue is referring to.

#[derive(Hash, Eq, PartialEq, Debug, Clone)]
pub struct VarSymbolInfo<'a> {
    pub lang_type: String, // language type - temp
    pub pointer_value: Option<PointerValue<'a>>,   // LLVM PointerValue
}

#[derive(Debug)]
pub struct FuncSymbols<'a> {
    pub name: String,                                    // LLVM function name
    pub var_symbols: HashMap<String, VarSymbolInfo<'a>>, // map of function local vars - var name, VarSymbolInfo
}

A sample of a single f64 variable in the symbol table looks like this:

FuncSymbols {
    name: "main",
    var_symbols: {
        "a": VarSymbolInfo {
            lang_type: "f64_type",
            pointer_value: Some(
                PointerValue {
                    ptr_value: Value {
                        name: "a",
                        address: 0x000056363441a030,
                        is_const: false,
                        is_null: false,
                        is_undef: false,
                        llvm_value: "  %a = alloca double, align 8",
                        llvm_type: "ptr",
                    },
               ...

When trying operate on variable (ss = "a") in a subsequent instruction I can read my symbol-table for "a", then call builder.build_load specifying context.f64_type() with the PointerValue that came from symbol-table lookup:

...
// try local - then global?
if func_symbols.has_var(ss) {
    if let Some(var_symbol_info) = func_symbols.get_var(ss) {

        let tmp_var = self.builder.build_load(
            self.ctx.f64_type(),
            var_symbol_info.pointer_value.unwrap(),
            var_symbol_info
             .pointer_value
             .unwrap()
             .get_name()
             .to_owned()
             .to_str()
             .unwrap_or(""),
           );

This works fine and returns the following:

FloatValue {
    float_value: Value {
        name: "a2",
        address: 0x000056363441f110,
        is_const: false,
        is_null: false,
        is_undef: false,
        llvm_value: "  %a2 = load double, ptr %a, align 8",
        llvm_type: "double",
    },
}

The question is whether or not I should be storing the detailed llvm_type_bit type information in my symbol-table? In the example, I fudged the first argument in builder.build_load to self.ctx.f64_type() to illustrate the approach. Ideally I would like to something like this to determine the llvm-type during the compiler execution:

       // pseudo-code to determine underlying type (f64, i64, i8, etc.)
       let my_nice_type = var_symbol_info.pointer_value.unwrap().<interrogate_for_type_info>

       let tmp_var = self.builder.build_load(
            my_nice_type,                          // self.ctx.f64_type(),
            var_symbol_info.pointer_value.unwrap(),
            var_symbol_info
             .pointer_value
             .unwrap()
             .get_name()
             .to_owned()
             .to_str()
             .unwrap_or(""),
           );

I am wondering how others have handled this? I know I could embed some type info in the symbol-table and then do a match prior the build_load call, but I am thinking that there must be a way to discover the detailed type info using the PointerValue/ptr that I already have?

thanks,

steve

[Pat-Lafon]

I'm interested to hear as well. In my little llvm-18 project I ended up creating a "wrapped pointer" which included the type information. https://github.com/sampsyo/bril/blob/40376ce96cc943279395fe9e914b8338f4143c59/bril-rs/brillvm/src/llvm.rs#L65-L70

If I recall, I also needed this because the runtime representation of a boolean is just an integer? Somewhere I had trouble distinguishing which value I had. Not sure if I missed something