feat: object ptr indirection #97
Conversation
Codecov Report
@@ Coverage Diff @@
## master #97 +/- ##
==========================================
+ Coverage 76.57% 76.84% +0.27%
==========================================
Files 127 130 +3
Lines 10275 10569 +294
==========================================
+ Hits 7868 8122 +254
- Misses 2407 2447 +40
Continue to review full report at Codecov.
|
crates/mun_codegen/src/ir/module.rs
Outdated
| @@ -104,6 +119,19 @@ pub(crate) fn ir_query(db: &impl IrDatabase, file_id: FileId) -> Arc<ModuleIR> { | |||
| let dispatch_table = dispatch_table_builder.finalize(&functions); | |||
| let fn_pass_manager = function::create_pass_manager(&llvm_module, db.optimization_lvl()); | |||
|
|
|||
| // Create the allocator handle global value | |||
| let allocator_handle_global = if dispatch_table.has_intrinsic(&crate::intrinsics::new) { | |||
There was a problem hiding this comment.
the allocato_handle_global should also be present if the clone intrinsic is present.
There was a problem hiding this comment.
If new is there, clone must also be there - and vice versa.
There was a problem hiding this comment.
Nonetheless if that is not the case in the future this will silently fail. Best to add it just in case.
There was a problem hiding this comment.
The new, clone, and - in the future - drop are all object management functions. They are all required if a struct type is defined. That should be the real test, I case because checking for everything potential future object management function doesn't scale too well.
There was a problem hiding this comment.
I agree but this check is to determine whether or not a global variable allocator handle is required. This is only the case if either of these methods is required no matter where they are used. Maybe in the future we would like to use one of these functions for a different use case. Than we dont have to touch the check.
The best check would be to check if one of the functions in the dispatch table are actually using the AllocatorHandle.
crates/mun_codegen/src/ir/body.rs
Outdated
| } | ||
| hir::StructMemoryKind::Value => { | ||
| if self.params.make_marshallable { | ||
| self.builder.build_load(value.into_pointer_value(), "deref") | ||
| let mem_ptr = self |
crates/mun_codegen/src/ir/body.rs
Outdated
| @@ -469,11 +496,21 @@ impl<'a, 'b, D: IrDatabase> BodyIrGenerator<'a, 'b, D> { | |||
| .. | |||
| }) => match s.data(self.db).memory_kind { | |||
| hir::StructMemoryKind::GC => { | |||
| self.builder.build_load(value.into_pointer_value(), "deref") | |||
| let mem_ptr = self | |||
There was a problem hiding this comment.
Maybe explain what is going on here?
|
So while looking a bit further, I found: http://llvm.org/doxygen/CloneModule_8cpp_source.html This clearly shows what gets copied and what doesn't. I already found that you can re-lookup global variables and function definitions by name. Maybe we can write a little wrapper around modules, global values and function definitions that enables us to better clone these things? |
|
I don't think this will help the situation. The generation of module IR requires target data information. You mentioned that that is not allowed to be set in the salsa db, so we need to move module IR generation out of salsa. Thus there is no need for us to copy anything. We can see if we can move more modular parts to salsa, though? |
We can totally store the target in the database! Its not a function of other input right? |
Wodann
force-pushed
the
feature/object-ptr-indirection
branch
from
e68435e to
325b66a
Compare
Beware of several changes:
#[salsa::input]which might affect incremental compilation.[IMPORTANT] To unblock PR #98, a resolution for 3) will be provided in a future PR!