[vodou]

Almost 16000 lines in a single source code file. I find this both admirable and unsettling.

[loeg]

Does it really matter where the lines are? 16,000 lines is still 16,000 lines.

[vodou]

Even though I do find your indifference refreshing I must say: it does matter for quite a few people.

[jiggawatts]

... yes.

If it was 16K lines of modular "compositional" code, or a DSL that compiles in some provably-correct way, that would make me confident. A single file with 16K lines of -- let's be honest -- unsafe procedural spaghetti makes me much less confident.

Compiler code tends to work "surprisingly well" because it's beaten to death by millions of developers throwing random stuff at it, so bugs tend to be ironed out relatively quickly, unless you go off the beaten path... then it rapidly turns out to be a mess of spiky brambles.

The Rust development team for example found a series of LLVM optimiser bugs related to (no)aliasing, because C/C++ didn't use that attribute much, but Rust can aggressively utilise it.

I would be much more impressed by 16K lines of provably correct transformations with associated Lean proofs (or something), and/or something based on EGG: https://egraphs-good.github.io/

[afiori]

Part of the issue is that it suggests that the code had a spaghettified growth; it is neither sufficient nor necessary but lacking external constraints (like an entire library developed as a single c header) it suggests that code organisation is not great.

[j-o-m]

I find the real question: are all 16,000 of those lines require to implement the optimization? How much of that is dealing with LLVM’s internal representation and the varying complexity of LLVM’s other internal structure?

[loeg]

What would it mean to implement the optimization without dealing with LLVM's internal structure? Optimizations don't exist in a vacuum.

[zahlman]

I do too, but I'm pretty sure I've seen worse.