amartosch (Mar 30 2025 at 11:46): amartosch (Mar 30 2025 at 11:46):Hello! I've looked at #10427 and it made me interested. I'd like to experiment with it. A first step might be evaluating performance impact of adding an Effect value type and plugging it through all instructions that have side-effects, without using it for optimization. However, I'm not sure if this would be worth it by itself.
The second step might be reworking elaboration to use effect lists instead of side-effecting skeleton (I'm sure, that this idea has been mentioned in some cranelift issue discussion, but I can't find it right now) and adding a couple of simple trap rewrites. For now I don't know how to implement the existing load/store optimizations with this approach, something has to be figured out.
What do you think? Is it worthwhile to pursue this avenue?
Chris Fallin (Mar 31 2025 at 03:33):I'm happy to see excitement for this! At the same time, I might inject a little bit of caution here: removing the side-effecting skeleton completely and scheduling according to only control-dep edges is a large step, and one that would require basically a research-problem-level consideration of how to integrate the new approach with the aegraphs framework. That's a lot of work to undertake upfront for uncertain payoff.
(Note also that Nick's writeup, and subsequent discussion re: recent sea-of-nodes discourse, note that we probably don't want to fully schedule from scratch; and that's what removing the skeleton would have us do. It seems more worthwhile to think about ways to deviate from the skeleton when we see that deps allow us to do so...)
It might be good to quantify opportunity first: encode control deps, then find examples in the wild where we know that the deps should let us reorder ops that we otherwise cannot. Once we have those, we know it's worthwhile, and we can experiment with the above with particular examples to drive us.
Last updated: Apr 08 2025 at 18:03 UTC