You can certainly go faster than LLVM if you're willing to sacrifice code quality (which B3 and SubZero do... or for the extreme example there is no way on Earth LLVM will catch up to TCC). But I think that DannyBee is totally right that "we can go faster than LLVM at the same level of code quality just by rewriting it" is magical thinking. As far as I'm aware, there are no design decisions in LLVM that are pervasive mistakes that sacrifice compilation speed for no reason [1]. If there's nothing you can point to and say "THIS is what I'm going to do better than LLVM", then you're probably going to end up at the same speed as LLVM. The parent comment's point is that none of the attempts to answer that question have been valid: so far the reasons cited have been based on misconceptions about what LLVM provides.
[1] Well, OK, I'm not a fan of SelectionDAGISel's interpreter. But switching that to AOT won't result in huge differences in compile times. (Note that it's been a couple of years since I really worked with LLVM closely.)
[1] Well, OK, I'm not a fan of SelectionDAGISel's interpreter. But switching that to AOT won't result in huge differences in compile times. (Note that it's been a couple of years since I really worked with LLVM closely.)