[clang] [clang] Expose MC target options through -mllvm (PR #210087)
Fangrui Song via cfe-commits
cfe-commits at lists.llvm.org
Thu Jul 16 10:11:32 PDT 2026
MaskRay wrote:
I am in favor of this change, but please can you trim the comments? I don't think it's worth mentioning this new large-eh-encoding in the comments: it's probably one of the least used options in the wild.
```
● Yes — this has a fairly strong AI smell, mostly from verbosity + duplication rather than outright wrong content. Here's the breakdown.
The tells
1. Near-verbatim duplication of a 5-line block across files. The "register flags" comment and the "seed" comment are each copy-pasted between BackendUtil.cpp and cc1as_main.cpp with only token swaps (clang's -mllvm → -cc1as -mllvm, llc, llvm-mc → llvm-mc). The same explanation then appears a third time in the test-file header and a fourth time in the PR body. Four restatements of one idea is a classic generated-text
signature.
2. Comment-to-code ratio is inverted. The actual change is two lines per file (one static decl, one init). Each is wrapped in a 4–5 line comment — so ~4 comment lines per code line. LLVM convention here would be one line.
3. Restating the obvious no-op case. Every seed comment ends with:
▎ // Absent any -mllvm flags this is equivalent to a default-constructed MCTargetOptions.
That's filler — InitMCTargetOptionsFromFlags() with no flags obviously yields defaults. It reads like padding to "cover all cases."
4. Explaining adjacent/other code.
- "Clang's own driver-derived settings below overwrite whatever they cover" — narrates the lines that follow.
- "whose accessors require the flags to have been registered" — narrates InitMCTargetOptionsFromFlags's internals.
This is the "multi-line comment explaining what other code does" pattern you named.
5. Test file re-explains what inline RUN comments already say. The 8-line header block spells out the precedence model, then each RUN group re-explains the same precedence for its specific case. The per-case comments are actually the useful ones; the header is redundant.
What's legitimately warranted
Not all of it is slop. A bare static llvm::mc::RegisterMCTargetOptionsFlags MCTargetOptionsFlags; genuinely looks like dead code, so one line saying "register MC flags so -mllvm can reach them (as llc/llvm-mc do)" is justified. And the precedence point (clang flags win over -mllvm) is the real non-obvious design decision worth stating — once.
Tightened version
// Register MC target-option flags (e.g. -large-eh-encoding) so they're
// reachable via -mllvm, as llc/llvm-mc do.
static llvm::mc::RegisterMCTargetOptionsFlags MCTargetOptionsFlags;
// Seed from -mllvm first; clang's own flags below take precedence.
Options.MCOptions = llvm::mc::InitMCTargetOptionsFromFlags();
That preserves every fact a reader needs and drops ~15 lines of restatement. So: yes, strong smell — driven by duplication and over-explanation, fixable by collapsing each block to one line.
```
https://github.com/llvm/llvm-project/pull/210087
More information about the cfe-commits
mailing list