Fix inlining order to correspond to source order. #9672
Conversation
| @@ -36,20 +36,15 @@ | |||
| // 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.
chriseth
force-pushed
the
fixRecompilation
branch
from
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. |
| @@ -36,20 +36,15 @@ | |||
| // 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.
| @@ -80,10 +80,20 @@ void FullInliner::run() | |||
|
|
|||
| // 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.