Model function calls as initializing expressions #3089
Conversation
Value bindings, temporary materializations, and initialization steps are created where necessary to transition between expression categories.
There was a problem hiding this comment.
I'm not certain about the exact structure we have of semantic nodes with this, but I think it's fine to start here.
My guess is that we may want to look at what is needed to lower this really nicely into LLVM IR and tweak the exact node structure between things like assign, the var or temporary allocation, and the initialize_from nodes, but it's hard to say what would be "right" just yet, and seems better to get the infrastructure in place and then look at tweaks.
Overall LG, some minor questions inline that aren't really blocking either way.
Don't create a return value slot for functions returning `()` explicitly, to match the calling convention for implicit `()` returns.
return slot or return a value. Update lowering to follow the new semantic model for returns.
returns in-place.
zygoloid
changed the title
zygoloid
changed the title
There was a problem hiding this comment.
@chandlerc Sorry for the large influx of new changes since your last review; I wanted to explore this a bit more and see how the direction pans out before committing to it. In the end the changes here aren't exactly an incremental extension of the previous state of the PR, so I think it probably makes more sense to treat this as a from-scratch review rather than an incremental diff compared to the prior PR.
zygoloid
dismissed
chandlerc’s stale review
Applies to substantially different PR.
There was a problem hiding this comment.
I'm pretty tired and so worried I'm missing something, but I think this largely makes sense.
I have some boring style nits in suggested edits, and a question (but not really a concern).
I'm not super delighted by the extensive temporaries, but I understand why this is a reasonably, faithful lowering. And it makes sense to get this and the other semantic things sorted out first, and then revisit things to try to tighten up the emitted LLVM IR.
So I think this LG.
Co-authored-by: Chandler Carruth <[email protected]>
Co-authored-by: Chandler Carruth <[email protected]>
Start treating function calls as initializing expressions instead of as value expressions.
This required adding support for expression categories. Value bindings and temporary materialization conversions are created where necessary to transition between expression categories. For a function call with a return slot, we speculatively create a materialized temporary before the call and either commit to it or replace it with something else later, once we see how the function call expression is actually used.
This change follows the direction suggested in #3133 for initializing expressions: depending on the return type of a function, the return value will either be initialized in-place or returned directly. This is visible in the semantics IR, which is a little unfortunate but is probably necessary as this is part of the semantics of the program.