On Tue Jul 4 09:11:46 2023 +0000, Giovanni Mascellani wrote:
Ugh, that's right. I hate that. I would name the new jump type something like `ITER_AND_CONTINUE`. The annoying detail is that that instruction has no meaning unless you know what the iteration block is, so it still happens that if you look at a IR dump is `ITER_AND_CONTINUE` you don't know which program is really being described. That instruction only make sense as long as you're inside the context in which the loop is being parsed, and at this point it doesn't look much better than just using `CONTINUE`, even if that's the solution that I originally disliked. Unfortunately I don't have any better solution in mind for the "do while" loop. I can't exclude there might be some clever trick with bison to pre-parse the loop body, than parse the "while" condition and then parse the body for real, but even if there was I'm not sure it would be worth the additional complexity of the parser. In conclusion, I think the best way to go is the original solution. I don't have a strong preference between overriding the `CONTINUE` jump, or introduce a new jump type.
Why does it need a new jump type? I think what needs to happen is instruction block added before every 'continue', for any loop type - 'for' will use iteration expression, do-while(expr) and while(expr) will use 'expr'. In all three cases presumably, expression without side effects will be eventually removed. The way do-while() is handled is a bit different too, they seem to unroll first iteration, and turning the loop into a 'while' one, but we probably don't have to do that.
For while() loop generated structure is:
- evaluate condition, without storing side effects; - break if false; - body; - evaluate condition, applying side effects this time;
do-while() turns into a while(), for() works the way this MR was going to make it work.
In conclusion, I think the best way to go is the original solution. I don't have a strong preference between overriding the `CONTINUE` jump, or introduce a new jump type.
Original solution to retroactively add instructions by scanning loop bodies?