Chooser scenario #103
Chooser scenario #103
Conversation
| local.get $left | ||
| invoke-func $stralloc-x | ||
| invoke-func $shared-x ;; make it a shared ptr | ||
| let (local $lpo owned<i32>) (result string) |
There was a problem hiding this comment.
minor nit: current function-references proposal requires this the other way around:
let (result string) (local $lpo owned<i32>)
TBH, I think it's more clear the way you have it, but I thought I'd mention.
There was a problem hiding this comment.
Agreed it reads more naturally to put results second, making let more like a function signature where params have been replaced by locals. Maybe we should change the function-references proposal...
There was a problem hiding this comment.
Ah, but there's a subtlety to let that I had missed. let introduces a new block, so it has a blocktype, which means w/ the multi-value proposal it's possible to have params and locals:
f32.const 1
i32.const 2
let (param i32) (result i64) (local f32)
;; i32:2 is still on top of the stack
;; f32:1 was consumed from the stack, and is now local 0
...
endI'm not sure there's value in having let params, but it does feel a bit odd to have the behavior differ significantly from the way other blocks work. It also means that a let block doesn't work at all like the locals at the beginning of a function (which means function inlining doesn't work naturally either).
There was a problem hiding this comment.
I missed that too. May need to revisit.
There was a problem hiding this comment.
Looks generally right. I made a few small requested tweaks.
Although I think it's valuable to show the final fused state, I do sortof question the value of showing all the intermediate states. What would be more valuable and general, I think, is to write a separate doc describing semi-formally the fusion algorithm, and then this doc could say "applying the [fusion] algorithm produces this final fused form", and then maybe have a bullet list that points out specific items of interest, like how the own expressions have been moved, etc.
| local.get $left | ||
| invoke-func $stralloc-x | ||
| invoke-func $shared-x ;; make it a shared ptr | ||
| let (local $lpo owned<i32>) (result string) |
There was a problem hiding this comment.
Agreed it reads more naturally to put results second, making let more like a function signature where params have been replaced by locals. Maybe we should change the function-references proposal...
|
Also: great job! This was a lot of work. |
| @@ -1,292 +0,0 @@ | |||
| # Interface instructions | |||
There was a problem hiding this comment.
Looks like something weird happened here; unrelated files getting deleted as part of this work. Maybe this branch isn't up-to-date with master?
There was a problem hiding this comment.
I think that this is because these files were accidentally included once. I deleted them in a subsequent commit but github fu is hard to figure out
| local.get $lsize | ||
| memory.copy "mem-i" "mem-x" ;; copy string across | ||
| local.get $ptr | ||
| i32.const 1 ;; initial reference count of 1 |
There was a problem hiding this comment.
If you remove this reference count above, remove it here too (and below).
Still one outstanding issue wrt form of let instructions.
This is an initial draft.
There are some variations on instructions and some instruction renaming.