[MooreToCore] [4/4] Add support for class.property_ref

[Scheremo]

Add a conversion pattern to translate moore.class.property_ref into an LLVM gep over the identified class struct, bridging the resulting pointer back to !llhd.ref<…> via unrealized_conversion_cast.

• Implement ClassPropertyRefOpConversion:
  • Validates result lowers to !llhd.ref<T>.
  • Ensures instance is !llvm.ptr.
  • Resolves the class’s identified struct and per-field GEP path via ClassTypeCache.
  • Emits llvm.getelementptr with cached indices and wraps back to ref.
• Register the pattern in populateOpConversion.
• Extend classes.mlir to verify that property_ref lowers to GEP.

[fabianschuiki]

LGTM! We'll need to think about how we are going to deal with that !llvm.ptr vs !llhd.ref<T> type mismatch. The !llhd.ref<T> expects to point to a signal that can then be used with llhd.prb and llhd.drv. Since classes are just bits of memory on the heap, that doesn't really work. Not sure how to reconcile this. Maybe we need a special !moore.ref type that is a pointer and can't be used with delayed and non-blocking assigns, which we could lower to !llvm.ptr 🤔

[Scheremo]

LGTM! We'll need to think about how we are going to deal with that !llvm.ptr vs !llhd.ref<T> type mismatch. The !llhd.ref<T> expects to point to a signal that can then be used with llhd.prb and llhd.drv. Since classes are just bits of memory on the heap, that doesn't really work. Not sure how to reconcile this. Maybe we need a special !moore.ref type that is a pointer and can't be used with delayed and non-blocking assigns, which we could lower to !llvm.ptr 🤔

I think the problem is mainly difficult for LValue accesses. I think we can add another operator for RValues in Moore (property_value?) to just return !T rather than !llhd.ref<T>.
On the other hand, what's the semantic issue with probing and driving on the heap?

[fabianschuiki]

I think the problem is that llhd.prb and llhd.drv expect to be interacting with an event queue. When the llhd.drv has a delay on it, it wants to have the !llhd.ref<T> represent something that has a mechanism to deal with the delay. When we lower to Arcilator for example, we may want to turn those into an !arc.event_queue<T>, with ops to push/pop entries into the queue. But classes only point at memory and want load and stores, so lowering that to !arc.event_queue<T> doesn't make a lot of sense. And we can't just make those !llvm.ptr, because that !moore.ref may be travelling through many layers of module hierarchy, each of which cannot "see" whether the ref was a signal where event queue mechanisms are allowed, or whether it was a class where they are disallowed.