You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like all we have to do is "pass through" expr->type, during codegen, into expr->ir->type. The issue of this happening everywhere is the hardest part, though, because it's currently designed in a way where expr->ir is set and then return happens immediately, but not in every case. So we could set it where codegen_expr returns, but then we may miss some instructions that were generated in between.
The other interesting thing; if an IR instruction's type can be understood from only it's arguments/children (like a call from the callee), then this means we can simply do the assigment within the creation function of the IR instruction, much like we mark uses.
So, really, we just have to figure out what the best way to actually assign expr->ir->type to expr->type within codegen_expr().
The text was updated successfully, but these errors were encountered:
It seems like all we have to do is "pass through"
expr->type
, during codegen, intoexpr->ir->type
. The issue of this happening everywhere is the hardest part, though, because it's currently designed in a way whereexpr->ir
is set and thenreturn
happens immediately, but not in every case. So we could set it wherecodegen_expr
returns, but then we may miss some instructions that were generated in between.The other interesting thing; if an IR instruction's type can be understood from only it's arguments/children (like a call from the callee), then this means we can simply do the assigment within the creation function of the IR instruction, much like we mark uses.
So, really, we just have to figure out what the best way to actually assign
expr->ir->type
toexpr->type
withincodegen_expr()
.The text was updated successfully, but these errors were encountered: