文章作者从LLVM项目维护者的角度，指出了LLVM存在的一些问题和不足，包括高层设计问题和具体实现问题，认为这些都是LLVM未来改进的机会。作者此前曾撰文讨论LLVM IR的设计问题，部分问题已得到解决。

LLVM项目的不足之处

作者nikic作为LLVM项目的核心维护者，撰文剖析了这一编译器基础设施存在的多个问题。文章从高层次问题到具体技术缺陷进行了全面梳理，以下是主要内容：

一、高层次问题 1. 评审资源不足 - 项目拥有数千名贡献者但缺乏专业评审人员 - 现有贡献模式要求PR作者自行寻找评审者，对新贡献者尤其不友好 - 建议采用类似Rust的PR分配系统

2. 代码变动频繁

• LLVM C++ API和IR设计持续演进
• 下游用户需要不断适配变更，特别是深度集成的后端开发者
• 反映了"上游优先"的开发哲学

3. 构建耗时

• 超过250万行C++代码导致编译缓慢
• 调试版本构建存在链接慢、内存占用高等问题
• 正在改进方案包括预编译头文件、动态链接库构建等

二、测试与质量 1. CI稳定性 - 200多个构建节点经常出现误报 - 大量无害错误通知掩盖了真正问题

2. 端到端测试不足

• 单元测试覆盖充分但缺乏完整优化管道测试
• 可执行测试集中在独立仓库，日常开发较少使用

三、技术债务 1. 中间表示设计 - undef值存在多用途问题和推理困难 - 浮点语义处理不完善 - 约束编码系统分散

2. 长期迁移项目

• 新Pass管理器十年仍未完全替代旧系统
• GlobalISel指令选择器同样面临漫长迁移

四、性能问题 1. 编译速度 - 即使-O0级别编译也较慢 - 替代后端LLVM TPDE展示出数量级优化空间

2. 性能跟踪缺失

• 缺乏官方性能监控基础设施
• 现有LNT系统体验差且数据不足

五、架构问题 1. ABI处理混乱 - 调用约定实现缺乏文档 - 目标特性与ABI耦合不当

2. 上下文/模块分离

• 类型/常量与数据布局分离导致设计复杂
• 跨上下文链接需经过比特码转换

文章最后指出，虽然存在诸多问题，但这些都是改进LLVM的机会而非否定其价值。作者欢迎读者补充未提及的其他问题。

（注：原文包含大量技术细节和内部讨论，本摘要保留了主要问题框架和关键论点，省略了部分专业术语解释和项目内部讨论细节。）

以下是评论内容的总结：

1. 对Rust安全性的质疑

   • 观点：认为Rust依赖难以审计的组件，其安全性承诺不切实际
   • 引用：
     "It's basically impossible to audit yet Rust is supposed to be safe"
     "I think infinite churn is the point" (评论1)

2. 对LLVM稳定性的肯定

   • 观点：LLVM IR近年来表现稳定，版本迁移相对容易
   • 引用：
     "LLVM IR is actually remarkably stable these days"
     "rebased from llvm 17 to 20 in a single day" (评论2)
   • 同时指出LICM寄存器压力问题可能与语言源类型有关

3. 对LLVM测试套件的建议

   • 观点：需要建立基于LLVM IR的完整测试套件，当前后端开发文档不足
   • 引用：
     "lack of documentation about SelectionDAG"
     "semantics aren't clearly documented" (评论3)

4. 对编译时间的批评

   • 观点：LLVM和Rust的编译时间过长影响使用体验
   • 引用：
     "Rust has horrible comptimes for anything larger"
     "a real PITA to use" (评论4)

总结呈现了关于安全性（1）、稳定性（2）、开发支持（3）和性能（4）四个维度的讨论，其中正面评价（2）与批评意见（1,3,4）保持平衡。