Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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



No 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.


Examples 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.


Eh, 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".


SROA 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: