Fix inlining order to correspond to source order. #9672
Conversation
| // g(10) | ||
| // mstore(1, x_8) | ||
| // } | ||
| // function f(x) |
There was a problem hiding this comment.
The order functions are processed changed here: Now, first g is inlined into f. Then we take a look at g and do not inline the call to f anymore because it is directly recursive now.
There was a problem hiding this comment.
Is the comment at the beginning of this file still relevant?
If it is, there is a typo there statemenst, might wanna fix that in this PR if the comment stays.
There was a problem hiding this comment.
I think it is still relevant.
219bc74 to
e72afcb
Compare
|
I'll try adding a yul-only test. |
|
Couldn't really come up with a test, but the change in the expectations at least show that this change has an effect. |
leonardoalt
left a comment
There was a problem hiding this comment.
It looks good, but I'm still wondering whether there would be an even more resilient way to handle this.
| // g(10) | ||
| // mstore(1, x_8) | ||
| // } | ||
| // function f(x) |
There was a problem hiding this comment.
Is the comment at the beginning of this file still relevant?
If it is, there is a typo there statemenst, might wanna fix that in this PR if the comment stays.
| if (holds_alternative<Block>(statement)) | ||
| handleBlock({}, std::get<Block>(statement)); | ||
|
|
||
| // TODO it might be good to determine a visiting order: |
There was a problem hiding this comment.
Isn't this +- what this PR does now?
There was a problem hiding this comment.
This PR makes it less chaotic, but the TODO suggests that we should find an order that results in better code.
Fixes #9573
No tests are added because I was not able to reproduce the reported issue in 0.7.0.