elliottt opened PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockWithArgs
that represents the pair of a block name with arguments to be passed to it. Rework the implementation ofjump
,brz
, andbrnz
to useBlockWithArgs
instead of storing the block arguments as varargs in the instruction'sValueList
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockWithArgs
that represents the pair of a block name with arguments to be passed to it. Rework the implementation ofjump
,brz
, andbrnz
to useBlockWithArgs
instead of storing the block arguments as varargs in the instruction'sValueList
.Some open questions:
- [ ] Does the return value of
num_fixed_actuals
function still make sense forbrz
andbrnz
even though they no longer store their control argument in the instruction's argument list?- [ ]The reworked builder api for
jump
,brz
, andbrnz
is not very nice to work with. Can we generate two variations of each function, one that takes aBlockWithArgs
and one that takes the pair ofBlock
andValue
slice?- [ ] I'm not 100% confident that I've found everywhere that we're using instruction arguments and block arguments interchangeably. Is there a good way to track this down beyond fuzzing?
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockWithArgs
that represents the pair of a block name with arguments to be passed to it. Rework the implementation ofjump
,brz
, andbrnz
to useBlockWithArgs
instead of storing the block arguments as varargs in the instruction'sValueList
.Some open questions:
- [ ] Does the return value of
num_fixed_actuals
function still make sense forbrz
andbrnz
even though they no longer store their control argument in the instruction's argument list?- [ ] The reworked builder api for
jump
,brz
, andbrnz
is not very nice to work with. Can we generate two variations of each function, one that takes aBlockWithArgs
and one that takes the pair ofBlock
andValue
slice?- [ ] I'm not 100% confident that I've found everywhere that we're using instruction arguments and block arguments interchangeably. Is there a good way to track this down beyond fuzzing?
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
elliottt updated PR #5464 from trevor/block-with-args
to main
.
cfallin submitted PR review.
cfallin submitted PR review.
cfallin created PR review comment:
Can we note that args are included here (in contrast to
label
below), and possibly also call itblock_with_args
throughout for clarity?
cfallin created PR review comment:
Likewise here, note that args are included
cfallin created PR review comment:
Is this correct for conditional branches? We need to skip the first arg from the elab stack, no?
cfallin created PR review comment:
The code duplication here is pretty unfortunate. Could we wrap it in a closure (
handle_use
or somesuch)?(Making it a closure will probably require closure args for borrows so the closure itself doesn't hold the borrows for too long)
cfallin created PR review comment:
Somewhat confusing to name this local
cell
if it's not actually a Cell or some other kind of interior mutability -- can we just call itfirst_elem
or something?
cfallin created PR review comment:
We can probably preallocate the list with the appropriate length upfront, since
args
is a slice and we know its length?
cfallin submitted PR review.
jameysharp submitted PR review.
jameysharp created PR review comment:
Huh, apparently
EntityList
doesn't have awith_capacity
constructor. Itsextend
method does make some use ofIterator::size_hint
though, so this reallocs the list at most once, when it has only one element in it. We could useIterator::chain
to preallocate the right size but I'm not convinced it's worth bothering.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockWithArgs
that represents the pair of a block name with arguments to be passed to it. Rework the implementation ofjump
,brz
, andbrnz
to useBlockWithArgs
instead of storing the block arguments as varargs in the instruction'sValueList
.Some open questions:
- [ ] Does the return value of
num_fixed_actuals
function still make sense forbrz
andbrnz
even though they no longer store their control argument in the instruction's argument list?- [x] The reworked builder api for
jump
,brz
, andbrnz
is not very nice to work with. Can we generate two variations of each function, one that takes aBlockWithArgs
and one that takes the pair ofBlock
andValue
slice?- [ ] I'm not 100% confident that I've found everywhere that we're using instruction arguments and block arguments interchangeably. Is there a good way to track this down beyond fuzzing?
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt submitted PR review.
elliottt created PR review comment:
Yep, this wasn't correct. Switching to using a map function for values made it much easier to get this right.
elliottt submitted PR review.
elliottt created PR review comment:
I've added some functions to abstract over the values of an instruction to avoid this sort of duplication, and am in the process of auditing uses of the existing arg accessors to determine if they need to be changed.
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockWithArgs
that represents the pair of a block name with arguments to be passed to it. Rework the implementation ofjump
,brz
, andbrnz
to useBlockWithArgs
instead of storing the block arguments as varargs in the instruction'sValueList
.Some open questions:
- [x] Does the return value of
num_fixed_actuals
function still make sense forbrz
andbrnz
even though they no longer store their control argument in the instruction's argument list?- [x] The reworked builder api for
jump
,brz
, andbrnz
is not very nice to work with. Can we generate two variations of each function, one that takes aBlockWithArgs
and one that takes the pair ofBlock
andValue
slice?- [ ] I'm not 100% confident that I've found everywhere that we're using instruction arguments and block arguments interchangeably. Is there a good way to track this down beyond fuzzing?
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockWithArgs
that represents the pair of a block name with arguments to be passed to it. Rework the implementation ofjump
,brz
, andbrnz
to useBlockWithArgs
instead of storing the block arguments as varargs in the instruction'sValueList
.Some open questions:
- [x] Does the return value of
num_fixed_actuals
function still make sense forbrz
andbrnz
even though they no longer store their control argument in the instruction's argument list?- [x] The reworked builder api for
jump
,brz
, andbrnz
is not very nice to work with. Can we generate two variations of each function, one that takes aBlockWithArgs
and one that takes the pair ofBlock
andValue
slice?- [x] I'm not 100% confident that I've found everywhere that we're using instruction arguments and block arguments interchangeably. Is there a good way to track this down beyond fuzzing?
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
jameysharp submitted PR review.
jameysharp created PR review comment:
I was concerned about silently deleting the "Can't use
.sum()
forCost
types" comment and then effectively implementing our own version ofIterator::sum
. But I see thatCost
does implementstd::ops::Add
and this statement was already relying on+
being overloaded. So I'm pretty sure this change is correct.
jameysharp submitted PR review.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockWithArgs
that represents the pair of a block name with arguments to be passed to it. Rework the implementation ofjump
,brz
, andbrnz
to useBlockWithArgs
instead of storing the block arguments as varargs in the instruction'sValueList
.Some open questions:
- [x] Does the return value of
num_fixed_actuals
function still make sense forbrz
andbrnz
even though they no longer store their control argument in the instruction's argument list?- [x] The reworked builder api for
jump
,brz
, andbrnz
is not very nice to work with. Can we generate two variations of each function, one that takes aBlockWithArgs
and one that takes the pair ofBlock
andValue
slice?- [x] I'm not 100% confident that I've found everywhere that we're using instruction arguments and block arguments interchangeably. Is there a good way to track this down beyond fuzzing?
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockCall
that represents the pair of a block name with arguments to be passed to it. (The mnemonic here is that it looks a bit like a function call.) Rework the implementation ofjump
,brz
, andbrnz
to useBlockCall
instead of storing the block arguments as varargs in the instruction'sValueList
.To ensure that we're processing value references from
BlockCall
values held in instructions, introduce three new functions onDataFlowGraph
:inst_values
,inst_values_mut
, andinst_values_mut_with
. The first function returns an iterator that traverses both the instruction and block arguments, while the latter two return a custom type that has a singlemap
function for mutating the values referenced. Theinst_values_mut_with
variant exists for cases where theDataFlowGraph
being mutated is held within another structure that needs to be mutated simultaneously.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
elliottt has marked PR #5464 as ready for review.
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockCall
that represents the pair of a block name with arguments to be passed to it. (The mnemonic here is that it looks a bit like a function call.) Rework the implementation ofjump
,brz
, andbrnz
to useBlockCall
instead of storing the block arguments as varargs in the instruction'sValueList
.To ensure that we're processing value references from
BlockCall
values held in instructions, introduce three new functions onDataFlowGraph
:inst_values
,inst_values_mut
, andinst_values_mut_with
. The first function returns an iterator that traverses both the instruction and block arguments, while the latter two return a custom type that has a singlemap
function for mutating the values referenced. Theinst_values_mut_with
variant exists for cases where theDataFlowGraph
being mutated is held within another structure that needs to be mutated simultaneously.I went through the existing uses of
inst_args
,inst_fixed_args
,inst_variable_args
, and their mut variants to decide whether or not they should be using the new iterator interface introduced above. Many needed to be migrated over, but there were cases where the original instruction was correct: the fuzzgen passes for fcvt and int_divz are examples of where the block args were never being indexed.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
elliottt requested jameysharp for a review on PR #5464.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockCall
that represents the pair of a block name with arguments to be passed to it. (The mnemonic here is that it looks a bit like a function call.) Rework the implementation ofjump
,brz
, andbrnz
to useBlockCall
instead of storing the block arguments as varargs in the instruction'sValueList
.To ensure that we're processing block arguments from
BlockCall
values in instructions, three new functions have been introduced onDataFlowGraph
that both sets of arguments:
inst_values
- returns an iterator that traverses values in the instruction and block argumentsmap_inst_values
- applies a function to each value in the instruction and block argumentsoverwrite_inst_values
- overwrite all values in an instruction and block arguments with values from the iteratorI went through the existing uses of
inst_args
,inst_fixed_args
,inst_variable_args
, and their mut variants to decide whether or not they should be using the new iterator interface introduced above. Many needed to be migrated over, but there were cases where the original instruction was correct: the fuzzgen passes for fcvt and int_divz are examples of where the block args were never being indexed.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
jameysharp submitted PR review.
jameysharp submitted PR review.
jameysharp created PR review comment:
I believe every part of this iterator supports access from both ends. If true, that means you can change the declaration this way, I think, and then callers can use
Iterator::rev
if they want.pub fn inst_values<'dfg>(&'dfg self, inst: Inst) -> impl DoubleEndedIterator<Item = Value> + 'dfg {
jameysharp created PR review comment:
Continuing the theme, how about renaming
block
here toblock_call
and extending the documentation to "Destination basic block, with its arguments provided"?
jameysharp created PR review comment:
I guess this blank line doesn't really need to be added here.
jameysharp created PR review comment:
Since it turned out that
inst_values
can return an iterator, you can replace all the uses offor_each
withfor
loops. In cases like this one that's good both because it minimizes the diff here and becausefor_each
is generally discouraged, as a Rust idiom. Switching back tofor
loops is a bigger win for the uses oftry_for_each
, which can just usebreak
statements or the?
operator instead ofControlFlow
.
jameysharp created PR review comment:
The comment isn't quite true: This vector can't be moved onto
self
, since the reason for introducing it is to avoid holding borrows ofself
across calls toself.elaborate_eclass_use
.But this function,
elaborate_block
, is only called fromelaborate_domtree
, so the vector could be allocated there and passed in by reference. That function in turn is called only once for the pass, so allocating the temporary storage there is as good as storing it onself
would be.
jameysharp created PR review comment:
I think most of the changes around here can be undone, assuming that
self.func.dfg.inst_values(inst)
can return aDoubleEndedIterator
.
jameysharp created PR review comment:
I've never had reason to use this Rust format-string syntax before, but this seems like a good place for it:
"let {0} = self.data_flow_graph_mut().block_with_args({0}_label, {0}_args);", op.name
jameysharp created PR review comment:
I'm amused that leaving the semicolon off here is legal, but let's not...
*arg = new_arg.value;
jameysharp created PR review comment:
A minor cleanup here is to call
Vec::drain
instead ofiter
,copied
, andclear
.self.func .dfg .overwrite_inst_values(inst, elab_values.drain(..));
jameysharp created PR review comment:
Minor style note: a
for
loop always callsinto_iter
, so you don't need to do it here.for mut block in self.insts[inst].branch_destination() {
jameysharp created PR review comment:
Like the
for_each
calls, now thatinst_values
is an iterator this can turn back into afor
loop with an early return.
jameysharp created PR review comment:
I don't see that this
count_values
method is used anywhere. Am I missing something?
jameysharp created PR review comment:
Since
map_inst_values
writes back unconditionally, let's not bother checking for unchanged values here either. (I expect rustfmt will want the outer curly braces removed too, but GitHub won't let me do suggestions on the full range of lines here.)resolve_aliases(&dfg.values, arg)
jameysharp created PR review comment:
into_iter
isn't necessary here either:for mut block in self.insts[inst].branch_destination() {
jameysharp created PR review comment:
Good call updating this comment. Maybe "a count only of the
Value
arguments" or something along those lines? It doesn't include various kinds of immediate arguments either.
jameysharp created PR review comment:
This closure is called with
block
set tobranch()
, which is then shadowed here with the same value. I think this closure shouldn't take any arguments.With that change, I think this will be the only call to
branch()
, so I'd inline it intocontinue_at
.
jameysharp created PR review comment:
Do you suppose this function should be renamed to
block_call
now, or perhapsmake_block_call
or something? I think calling itblock_with_args
isn't terrible but it's worth taking a moment to think about it.Also, there are various comments that still refer to
BlockWithArgs
, like this one and a bunch of places ininstructions.rs
.
jameysharp created PR review comment:
I wonder if this alternative is any better (after applying rustfmt, anyway). What do you think?
let branch_args = self.f.dfg.insts[inst].branch_destination().into_iter().flat_map(|block| block.args_slice(&self.f.dfg.value_lists));
jameysharp created PR review comment:
Another place where
into_iter
isn't necessary:for branch in dfg.insts[pred.inst].branch_destination_mut() {
elliottt submitted PR review.
elliottt created PR review comment:
I'm surprised this wasn't caught by rustfmt!
elliottt deleted PR review comment.
elliottt submitted PR review.
elliottt created PR review comment:
It was left-over from an earlier refactoring, thanks for catching it!
elliottt submitted PR review.
elliottt created PR review comment:
Ah, this was to avoid a warning. Do you mind if we leave these for now and remove them once
branch_destination
returns a slice?
elliottt updated PR #5464 from trevor/block-with-args
to main
.
jameysharp created PR review comment:
Oh, that makes sense! Sure, leave the
.into_iter()
calls in, that's fine.
jameysharp submitted PR review.
jameysharp submitted PR review.
jameysharp created PR review comment:
I guess the current CI failure is that this
use
item is no longer necessary.
elliottt submitted PR review.
elliottt created PR review comment:
I've removed the comment and implemented that change, thanks!
elliottt submitted PR review.
elliottt created PR review comment:
I like it!
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockCall
that represents the pair of a block name with arguments to be passed to it. (The mnemonic here is that it looks a bit like a function call.) Rework the implementation ofjump
,brz
, andbrnz
to useBlockCall
instead of storing the block arguments as varargs in the instruction'sValueList
.To ensure that we're processing block arguments from
BlockCall
values in instructions, three new functions have been introduced onDataFlowGraph
that both sets of arguments:
inst_values
- returns an iterator that traverses values in the instruction and block argumentsmap_inst_values
- applies a function to each value in the instruction and block argumentsoverwrite_inst_values
- overwrite all values in an instruction and block arguments with values from the iteratorI went through the existing uses of
inst_args
,inst_fixed_args
,inst_variable_args
, and their mut variants to decide whether or not they should be using the new iterator interface introduced above. Many needed to be migrated over, but there were cases where the original instruction was correct: the fuzzgen passes for fcvt and int_divz are examples of where the block args were never being indexed.Fixes #5451
<!--Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt edited PR #5464 from trevor/block-with-args
to main
:
Add a new type
BlockCall
that represents the pair of a block name with arguments to be passed to it. (The mnemonic here is that it looks a bit like a function call.) Rework the implementation ofjump
,brz
, andbrnz
to useBlockCall
instead of storing the block arguments as varargs in the instruction'sValueList
.To ensure that we're processing block arguments from
BlockCall
values in instructions, three new functions have been introduced onDataFlowGraph
that both sets of arguments:
inst_values
- returns an iterator that traverses values in the instruction and block argumentsmap_inst_values
- applies a function to each value in the instruction and block argumentsoverwrite_inst_values
- overwrite all values in an instruction and block arguments with values from the iteratorI went through the existing uses of
inst_args
,inst_fixed_args
,inst_variable_args
, and their mut variants to decide whether or not they should be using the new iterator interface introduced above. Many needed to be migrated over, but there were cases where the original instruction was correct: the fuzzgen passes for fcvt and int_divz are examples of where the block args were never being indexed.
<!--Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
jameysharp submitted PR review.
jameysharp submitted PR review.
jameysharp created PR review comment:
Should this just use
inst_values
, now that that's an iterator? I'm not sure I quite understand how the stack is being used here, but I don't _think_ it requires these to be in separate iterators, so I think this simplification should be okay.stack.push(f.dfg.inst_values(src_inst));
jameysharp created PR review comment:
Would you mind passing the
block
from the caller? It's already done the necessary pattern match and can avoid the.unwrap()
.
jameysharp created PR review comment:
Most (maybe all?) of this complexity should go away when the
br_if
migration is done, so I don't care whether you make this change before merging, but:I just noticed we can delete the
BranchOrderKind
enum and deduplicate thereplace
calls below by just directly returning which opcode theBranch
should use after this rewrite:Opcode::Brz => Opcode::Brnz, Opcode::Brnz => Opcode::Brz,
We could also get rid of some noise by moving the
replace
calls inside the inner match, instead of returning a tuple below and having to let-bind it above.
elliottt created PR review comment:
Yep, it definitely should, thanks for catching that one!
elliottt submitted PR review.
elliottt created PR review comment:
I remember what happened when I tried this with a previous version of this branch: we need to change the element type of
stack
toBox<dyn Iterator<Item=Value>>
for that change to work becauseinst_values
returns animpl Iterator<Item=Value>
. Will the heap indirection be worth the change here?
elliottt submitted PR review.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt submitted PR review.
elliottt created PR review comment:
We went back and forth on alternate approaches here in a DM, and @jameysharp found a great one that he's going to push in a separate PR.
elliottt submitted PR review.
elliottt created PR review comment:
This refactoring was made in #5586.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt updated PR #5464 from trevor/block-with-args
to main
.
elliottt merged PR #5464.
Last updated: Dec 23 2024 at 13:07 UTC