[DannyBee]

Interestingly, much of their complaints around pointer chasing, etc, are things LLVM plans on solving in the next 6-8 months. i'm a bit surprised they never bothered to email the mailing list and say "hey guys, any plans to resolve this" before going and doing all of this work. But building new JITs is fun and shiny, so ...

[Joky]

LLVM instruction selection is slow, there is a "fast-path" which hasn't received much attention (it is only used for -O0 in clang). The new instruction selector work just started and will take a couple of years, considering the tradeoff between spending 3 months on it and waiting a few years for LLVM to be improved (without any guarantee of LLVM reaching the same speed as what they did). See also some thoughts from a LLVM developer on optimizing for high-level languages: http://lists.llvm.org/pipermail/llvm-dev/2016-February/09546...

[DannyBee]

The problem with the path they've taken is it has a finite end.

This is why, when they compare it to v8/etc, it's kind of funny. They all have the same curve.

Basically all of these things, all of them, end up with roughly the same deficiencies once you cherry pick the low hanging fruit[1], and then they stall out, and get replaced a few years later when someone decides thing X can't do the job, and they need to write a new one. None of them ever get to a truly good state.

Rinse, wash, repeat.

The only thing these things make real progress, is by doing what LLVM did - someone works on it for years.

Let me quote a former colleague at IBM - "there is no secret silver bullet to really good compilers, it's just a lot of long hard work". If you keep resetting that hard work every couple years, that seems ... silly.

TL;DR If you really believe they've totally gotten everywhere they need to be in 3 months, i've got a bridge to sell you

[1] For example, good loop vectorization and SLP vectorization is hard.

[nadav256]

Danny, you mentioned loop and SLP vectorization. One thing that bothered me while watching the development of the SLP and Loop vectorizers over the last two years was that developers who cared about SPEC added functionality that increased compile time. I remember one change that added a second phase that scans the entire IR in the SLP vectorizer to get a 1.4% win in one of the SPEC programs. I hoped the FTL project would be able to enable the vectorizers, but to my disappointment the vectorizers are too slow to justify the boost on javascript workloads.

[Alphasite_]

I imagine they did, considering the head of LLVM is a (probably distant) coworker of theirs.

[DannyBee]

"The head of LLVM" - no such thing exists, but okay. (People have such weird ideas about how these projects work in practice).

[Alphasite_]

I realise that, but you understand the intent of the comment which is the point.