It is useful to keep statistics on how many instructions we have
compressed, so we can see if future changes are increasing or decreasing this
number.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 43576 Build 44492: arc lint + arc unit
Event Timeline
LGTM. My only concern was if it made sense to use the same statistic to count in both places, and if we could end up double counting the instructions emitted (now, or in a future LLVM version). After a quick look I didn't really see other targets using the same approach, but I also can't think of a way where this ends up actually being problematic.
(Nipick: maybe put a comment in the statistic reminding people that the linker may further compress some of the instructions we emitted uncompressed?)
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp | ||
---|---|---|
1618–1621 | under if (Res) too ? |
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp | ||
---|---|---|
1618–1621 | This was covered in rGa0f43b0043581b37b10d105a85f0653704d3657b - I just need to rebase this patch. |
My understanding is that instructions only go through one of these functions. RISCVAsmParser.cpp is used by the assembler only, and the RISCVAsmPrinter.cpp is only used by LLVM CodeGen. This should mean that instructions are not double-counted (today). Yes I'm not sure why we have both, I think @asb did this to ensure better layering.
Note, the statistics are not the same. Statistics are namespaced by DEBUG_TYPE, which is why I had to define it in RISCVAsmParser.cpp.
(Nipick: maybe put a comment in the statistic reminding people that the linker may further compress some of the instructions we emitted uncompressed?)
The point in these statistics is to track how good LLVM is at compressing instructions (which may change depending on optimisation heuristics we implement eventually). I don't see this as being used by end users much, if at all.
Both are necessary for completeness, and are independent paths for MCInst generation. We did go back and forth a fair bit on exactly where the compression hook should be called and that seemed the most sensible option - I forget the full analysis, but there wasn't a single place we could stick it while remaining localised to the RISC-V backend.
under if (Res) too ?