Use indirect call effects in LinearExecutionWalker#8738
Conversation
stevenfontanella
force-pushed
the
linear-execution-walker-indirect-call
branch
2 times, most recently
from
1bb3583 to
b8567b2
Compare
stevenfontanella
changed the title
| ;; that the only possible target for this ref is $const in a closed world, | ||
| ;; which wouldn't block our optimizations. | ||
| ;; TODO: Add effects analysis for indirect calls. | ||
| ;; With --closed-world enabled, we can tell that this can only possibly call |
There was a problem hiding this comment.
I think --closed-world isn't even necessary for this, since this module has no imports or exports. There's no way for an outside function reference to sneak in.
There was a problem hiding this comment.
Good point, is it worth doing any indirect call analysis in the open world case? We could aggregate type effects unconditionally, and if we see a function ref that's imported or exported then invalidate the effects for that type and all subtypes. But any exported table of funcref would be enough to stop all analysis, and I know that many users use --closed-world anyway?
In practice, we only do indirect call analysis if --closed-world is enabled, so I think the comment is appropriate. It's still true that --closed-world is enough to determine that $const is the only possible callee here.
There was a problem hiding this comment.
I think we should do indirect call analysis in open world, too. It just needs to respect the public/private type classification it gets from module-utils.h. (In the long run we want everything to run in both open-world and closed-world and fully encapsulate the difference in the type visibility classfication.)
There was a problem hiding this comment.
I'll leave this alone since I think the comment is still accurate for now based on #8754. In the future we can change GlobalEffects to look at public/private for types instead of --closed-world at which point we can change this.
|
I would also fuzz this heavily, just in case. |
Ran overnight for 16k iterations with no issues. |
stevenfontanella
force-pushed
the
linear-execution-walker-indirect-call
branch
from
b8567b2 to
3cda588
Compare
| (drop (call_indirect (type $const-type) (i32.const 0))) | ||
| ;; Similar to above, except here we can tell that the indirect call may | ||
| ;; throw so optimization is halted. | ||
| (drop (call_indirect (type $throw-type) (i32.const 0))) |
There was a problem hiding this comment.
I guess SimplifyLocals could be improved to optimize here despite the throws effect, but that's unrelated to this PR.
3 participants
Part of #8615. Follows up from #8637 now that global effects for indirect calls has been added.
Allows LinearExecutionWalker to not halt and continue scanning when an indirect call is encountered in the case the global effects have been computed under
--closed-worldand we determined that the indirect call can't have any throw effects. LinearExecutionWalker is used in the following passes: