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
When building an if-else–construct using branch_conditional(cond, true_label, false_label, …) I need the OpLabel-ids before they are generated.
If branch_conditional returned &mr::Instruction and forward references were Cell<Word> instead of Word I could patch it later. Though this would allow anyone with a non-mut reference to mess things up.
The text was updated successfully, but these errors were encountered:
Never mind, I should’ve read the documentation. Though even if I use builder.id() how do I make a later basic block use exactly that id instead of the next auto-generated one? The builder gives no mutable references to any of the objects it creates, as far as I can tell.
Yep, confirmed. This is a flaw in the current builder API. I knew forward references would bite me so I left some comments in the doc about it. However, the solution covers some case but not all. I'll fix the rest soon. :)
Returning an instruction to allow fixing up things later was truly the way I'd like to take previously. But after a second thought, wrapping all instructions with Cell introduces too much overheads into the current data representation. So I think I'll instead change the builder methods to take an additional Option<spirv::Word> for result ids. It brings in some boilerplate code when using the API, but it keeps the current simple data representation.
When building an if-else–construct using
branch_conditional(cond, true_label, false_label, …)
I need the OpLabel-ids before they are generated.If branch_conditional returned
&mr::Instruction
and forward references wereCell<Word>
instead ofWord
I could patch it later. Though this would allow anyone with a non-mut reference to mess things up.The text was updated successfully, but these errors were encountered: