4 ms·

"designing an IR" may or may not be hard - designing a close-to-optimal generic IR that can be sourced from many different languages and target many different b

by klik99 3y ago

"designing an IR" may or may not be hard - designing a close-to-optimal generic IR that can be sourced from many different languages and target many different backends, each with their own idiosyncrasies on both ends may not even be "hard" by some definition of hard (apparently one where a lot of work can still be easy), but then designing optimizations and transforms that practically work pretty good across all those hacks and edge cases, enough that major companies now base their toolchains on your optimizations? I'm pretty sure that's gotta be hard

gavinhoward 3y ago
Yes, that's hard. But the original comment was solely about IR design. For me, I'm not worried about companies adopting my platform. I just want to not have a C++ dependency. Yes, I hate C++ that much. So I'm not terribly worried about other languages. I am worried about many different backends, though.
- klik99 3y ago
  Previous comment was about optimizations, though I can see how it was confusing. Someone said: "Question to pros: Things like constant propagation, loop unrolling, TCO, memory reuse etc., seem simple in theory. Yet why do languages end up depending on LLVM and not implement these algorithms on their own and avoid a monstrous dependency?" - response said optimizations are hard and recommended designing an IR specifically to optimize for it "pick any language that has a parser impl and design an IR for it and then optimize it (designing an IR from scratch can't be that hard can it?)" I have a commercial product that's a development tool that get a huge chunk of value from targeting x64, arm/arm64 and wasm - I actually do like C++ but I don't like the massive bloat of LLVM - however just getting all these backends for free and how easy it was to get a 90% there thing going by writing parser -> IR and then having everything else just taken care of was worth it for me. Compilation speeds def hurt from LLVM dependency, but it's a tradeoff.

by klik99 3y ago

gavinhoward 3y ago

Yes, that's hard. But the original comment was solely about IR design. For me, I'm not worried about companies adopting my platform. I just want to not have a C++ dependency. Yes, I hate C++ that much. So I'm not terribly worried about other languages. I am worried about many different backends, though.

klik99 3y ago
Previous comment was about optimizations, though I can see how it was confusing. Someone said: "Question to pros: Things like constant propagation, loop unrolling, TCO, memory reuse etc., seem simple in theory. Yet why do languages end up depending on LLVM and not implement these algorithms on their own and avoid a monstrous dependency?" - response said optimizations are hard and recommended designing an IR specifically to optimize for it "pick any language that has a parser impl and design an IR for it and then optimize it (designing an IR from scratch can't be that hard can it?)" I have a commercial product that's a development tool that get a huge chunk of value from targeting x64, arm/arm64 and wasm - I actually do like C++ but I don't like the massive bloat of LLVM - however just getting all these backends for free and how easy it was to get a 90% there thing going by writing parser -> IR and then having everything else just taken care of was worth it for me. Compilation speeds def hurt from LLVM dependency, but it's a tradeoff.