[BitcodeAnalyzer] allow a motivated user to dump BLOCKINFO

Why this change?

Without it, the dumper will prematurely emit the end of the BLOCKINFO_BLOCK.

There are two cases:

• Not dumping the BLOCKINFO_BLOCK (the default): emit an empty XML-element-thingy
• Dumping the BLOCKINFO_BLOCK: actually visit the BLOCKINFO_BLOCK, and let its dumper handle the fully XML-element-thingy

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.

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?

What Theresa suggests makes sense to me.

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.

Done!

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: ...

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.)

I don't quite get why, because the block is guarded by:

if (O && !O->DumpBlockinfo) ; how can we get here and O && have any effect?

Ah my bad: there is a if (O && !O->DumpBlockinfo) but it only guard a single line, not the entire block.

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.