Sept. 25, 2023
2:22 p.m.
On Wed Jul 5 09:07:20 2023 +0000, Giovanni Mascellani wrote: > > For while() loop generated structure is: > > > > * evaluate condition, without storing side effects; > > * break if false; > > * body; > > * evaluate condition, applying side effects this time; > I'm not sure what you mean by this. You seem to imply that if the > `while` condition is false, then its side effects are not evaluated, but > I don't see this happening. I think the `while` loop is the easiest one, > you just evaluate (with side effects) the condition at the beginning and > break if it is false, then run the body. Jumps `continue` and `break` > automatically work properly, without doing anything else. The problem > with `continue` is only with `do`-`while` and `for` loops, and it can be > solved e.g. by copying the iteration (for `for` loops) or condition (for > `do`-`while` loops) code before the `CONTINUE` jump. Jump `break` still > needs no special treatment, I think. Unrolling the first iteration is > also an option, I suppose, but it doesn't seem to make our life simpler. > Or does it? > > Original solution to retroactively add instructions by scanning loop bodies? > Yeah. Apparently with `do`-`while` loops that's the only feasible solution. > > Why does it need a new jump type? > My understanding is that Zeb prefers to distinguish `CONTINUE` jumps > that have already been replaced with iteration/condition code from those > that are not. So the idea would be: > * While parsing the loop body, insert `ITER_AND_CONTINUE` jumps when > `continue` statements appear; > * Then, once you know the iteration/condition code, scan again the > generated code and replace every `ITER_AND_CONTINUE` jump with the > iteration/condition code and a `CONTINUE` jump. > As I said, I don't have a strong opinion between this and what you > originally did (i.e., using `CONTINUE` jumps for the get-go). Pushed something for all of this, please take a look. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/245#note_46692