This adds the --dump-blockinfo flag to llvm-bcanalyzer, allowing a sufficiently motivated user to dump (parts of) the BLOCKINFO_BLOCK block. The default behavior is unchanged, and --dump-blockinfo only takes effect in the same context as other flags that control dump behavior (i.e., requires that --dump is also passed).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Sorry for the churn; rebased the commit so that it sits on the latest main instead of an old one.
Another gentle ping for review here. Please let me know if there's anything else I can do.
To make it convenient to get reviewing, please upload the patches with context, see documentation - https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-command-line
git show HEAD -U999999 > mypatch.patch or arc diff HEAD~
Please add a test. Maybe in llvm/test/tools/llvm-bcanalyzer/ ?
llvm/lib/Bitcode/Reader/BitcodeAnalyzer.cpp | ||
---|---|---|
747 | Why this change? |
llvm/lib/Bitcode/Reader/BitcodeAnalyzer.cpp | ||
---|---|---|
747 | Without it, the dumper will prematurely emit the end of the BLOCKINFO_BLOCK. There are two cases:
|
Added a test; made some small fixes to the --help output and file comments.
llvm/test/tools/llvm-bcanalyzer/dump-blockinfo.test | ||
---|---|---|
2 | N.B.: Please let me know if using llvm-stress like this isn't advisable; I can check in a test input instead if that's preferred. |
Yes, we don't use llvm-stress in testcases. I think you take input .bc file from llvm/test/Other/Inputs. Other than that testcase, changes LGTM but @mehdi_amini might give it final approval.
Screenshot of the output of --dump-blockinfo flag.
llvm/test/tools/llvm-bcanalyzer/dump-blockinfo.test | ||
---|---|---|
2 | Can you make this a small .ll test instead (see examples in other test directories) and just run it through opt to get a bitcode and then run llvm-bcanalyzer on that? And then is it possible to check some of the expected contents of the blockinfo section? |
Thanks for pulling me in, but I really haven't worked in this area for a long time :)
If you have a hard time finding a reviewer you can always ping the code owner for bitcode and ask them to help find one.
Happy to help thought: so LGTM with the inline comments addressed!
llvm/lib/Bitcode/Reader/BitcodeAnalyzer.cpp | ||
---|---|---|
762 | ||
llvm/test/tools/llvm-bcanalyzer/dump-blockinfo.test | ||
2 | What Theresa suggests makes sense to me. |
Avoid llvm-stress in test, more detailed checks.
llvm/lib/Bitcode/Reader/BitcodeAnalyzer.cpp | ||
---|---|---|
762 | O is Optional<BCDumpOptions> here, so I think we need the O && ... check here. When I remove it, running llvm-bcanalyzer with no options (i.e. just llvm-bcanalyzer foo.bc) causes an abort in the Optional. | |
llvm/test/tools/llvm-bcanalyzer/dump-blockinfo.test | ||
2 | Done! |
llvm/test/tools/llvm-bcanalyzer/dump-blockinfo.test | ||
---|---|---|
2 | Generally we avoid using bitcode directly as a test input, because the format can change. What I would suggest is to llvm-dis that bitcode into a .ll file. Then just make that the test file with the command and tests in it. I.e. rather than a .test extension like this, have something like a llvm/test/tools/llvm-bcanalyzer/dump-blockinfo.ll test that contains your llvm-dis'ed bitcode file, then add commands in it like: ; RUN: llvm-as < %s | llvm-bcanalyzer --dump --dump-blockinfo | FileCheck %s ; CHECK: ... |
llvm/test/tools/llvm-bcanalyzer/dump-blockinfo.test | ||
---|---|---|
2 | Unfortunately, I think we need the direct bitcode input here: LLVM's bitcode writer is allowed to make arbitrary abbreviation decisions in the BLOCKINFO_BLOCK, so round-tripping through the textual form isn't guaranteed to produce the same records in BLOCKINFO_BLOCK (or even a BLOCKINFO_BLOCK at all). (Separately, the test input I'm using here isn't valid LLVM IR, since it's just a bitstream fragment. I copied it from llvm/test/Other/Inputs per @xgupta's example, where it was already separately checked in.) |
llvm/test/tools/llvm-bcanalyzer/dump-blockinfo.test | ||
---|---|---|
2 | Ah ic. Hmm, perhaps you can just do the new testing directly in llvm/test/Other/bcanalyzer-block-info.txt? I didn't realize there were other llvm-bcanalyzer tests in that test directory - makes sense to put it there and probably consolidate it into that existing test which also tests how that info gets dumped. |
Moved the new test to llvm/test/Other/bcanalyzer-dump-blockinfo-option.txt per @tejohnson's suggestion.
(I kept it in its own file for consistency with the other llvm-bcanalyzer tests in that dir.)
Why this change?