Hacker News new | ask | show | jobs
by dochtman 3782 days ago
But isn't it true that some of the things you ended up doing would make sense for LLVM, or would most of them be invalidated by the kinds of optimization passes that are common in LLVM?

E.g. stuff like making the in-memory IR representation better cacheable certainly sounds like it's all-upside, and LLVM should just learn from your project.

2 comments

LLVM's use of a very rich (and hence not as memory efficient) IR is deeply rooted. Phases assume that given any value, you can trace your way to its uses, users, and owners. The LLVM code I've played with assumes this all over the place, so removing the use lists and owner links as B3 does would be super hard. B3 can do it because we started off that way.
There is a tradeoff between having a dense and compact IR and being able to modify it very easily. LLVM tends to focus on the second. Even if there are plan to balance a bit more, this will take a lot of time (and benchmarking).