cl: fold constant comparisons before lowering - #2257
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Review summary
Clean, well-scoped change. The new foldConstComparison helper folds constant-operand comparisons to a boolean at IR-generation time, which lets LLVM prove the dead branch and drop the reference to the bodyless @main.fail, resolving the removed issue9608 xfail. Correctness looks sound:
- Only the six comparison operators are folded; arithmetic/bitwise ops fall through unchanged.
- Both operands must be
*ssa.Constwith non-nilValue, so typed and untyped nil comparisons are correctly excluded (verified byTestFoldConstComparison) and still take the existing nil path. constant.Comparematches Go semantics for every constant kind a non-nil*ssa.Const.Valuecan hold. Ordering ops onbool/complex(which would panic inconstant.Compare) are rejected upstream by Go's type checker, so they can't reach here. NaN is not representable as a Go constant, so no float divergence.
No security or performance concerns; the fold reduces emitted IR and downstream optimizer work.
Findings below are minor/optional — nothing blocking.
Minor
cl/compile.go:1595—foldConstComparisonreturns(bool, bool)where the first is the result and the second is the "folded" flag. Two unnamed bools where order matters is easy to misread. Consider named returns(result, folded bool)and/or a one-line doc comment noting that nil constants are intentionally skipped (so a future refactor doesn't accidentally fold typed/untyped nil throughgo/constant). Consistent with the terse local style, so optional.
LLGo baseline benchmarks
Program measurements
Core language and compiler benchmarks
No main baseline exists yet; all metrics are marked Warning
|
|
The Ubuntu failure was a stale |
Summary
This keeps the fix generic: constant string comparisons no longer become runtime StringEqual calls, so ordinary LLVM optimization can eliminate their unreachable branches and bodyless references.
Testing
A combined full cl/internal/build run reached the standard 10-minute package timeout while still progressing through unrelated generated-program and PCLN integration cases; no related assertion failure was observed.