4 ms·
> limiting the scope to a few blocks Yeah so like that doesn’t scale. The interesting optimizations involve reasoning across thousands of blocks And my point
by pizlonator 1y ago
> limiting the scope to a few blocks
Yeah so like that doesn’t scale.
The interesting optimizations involve reasoning across thousands of blocks
And my point is there is no reliable general purpose solution here. „Only works for a few blocks at a time” is not reliable. It’s not general purpose
- viraptor 1y agoNo optimisation currently done in production compilers (that I know of) work on more than a few blocks. I haven't seen anyone claim they're not general purpose or don't scale yet, or are not reliable. Meanwhile the patch we're discussing is 2 functions, 3 blocks each. So in this context we're not talking about anything crazy.
- pizlonator 1y agoExamples of optimization passes in llvm that reason across arbitrary numbers of blocks: - SROA - GVN - regalloc And those are just the heaviest hitters. In fact most optimization passes are capable of performing changes that impact many blocks at once.
- viraptor 1y agoEh, kinda? I mean regalloc is not an optimisation pass. And SROA/GVM go through whole functions, but they don't really optimise across blocks. They do local changes only with information from previous blocks available. I meant that I don't know of anything that makes modifications across multiple blocks as one complex change. Even licm pokes one thing at a time from one block to a different one. There's no complex "let's replace this kind of cross-block pattern with a different equivalent code that changes multiple blocks at the same time".
- pizlonator 1y agoSROA absolutely does a coordinated modification across an arbitrary number of blocks whenever it kills an alloca. GVN has cases where it’ll also make a coordinated change across multiple blocks And those are just two passes. I’m not mentioning the many other passes that have this property just for the sake of brevity.