[PATCH] D83725: [llvm-mc] Add --doc-id=<id> to support multiple documents in a file
David Blaikie via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Jul 13 16:56:28 PDT 2020
dblaikie added a comment.
In D83725#2148813 <https://reviews.llvm.org/D83725#2148813>, @MaskRay wrote:
> In D83725#2148760 <https://reviews.llvm.org/D83725#2148760>, @dblaikie wrote:
>
> > > yaml2doc supports --docnum=<num> to allow multiple documents in a file. Combing tests prudently can improve readability. This patch adds a similar --doc-id=<id> to llvm-mc.
>
>
> I am open to an alternative to "doc". llvm-mc supports both assembly and disassembly (both are in textual forms). I'd expect "obj" to refer to a binary form input, which isn't the case for llvm-mc.
Fair point - 'asm', perhaps? (think that's probably fine/close enough for the disassembly that people aren't going to be too confused by it)
>> Presumably "doc" makes sense in the yaml2doc context - perhaps "obj" would make more sense in llvm-mc
>>
>> But I'm not sure it's the best direction - we have lots of input files (testing IR, testing C++, etc) where we don't have this ability to have multiple distinct inputs in one file & it seems to work OK? Is there something different about llvm-mc that motivates this feature here especially?
>
> If we want to test local things (how IR is lowered, how instructions are assembled, how bytes are disassembled), whatever the containing function is named does not matter. Say, we have a function `foo`, and we want to test a variant of it, we can just add another function `bar`, duplicating the content in `foo` and adding some variance.
>
> However, this works poorly for some "global resources". For example, if we want to test the content of .strtab, the order of section headers, etc. We can't say: the first 3 input lines test the case of 3 symbols, the last 4 input lines test the case with 4 symbols - .symtab is a singleton, if you want to test 4 symbols, the 3 symbol case is not tested any more.
>
> What we currently do is to add another test file, with some variation to the first test file. It is not rare for me to diff two test files and find the differences. It'd be easier if two similar things are tested in one file, with a comment explaining the differences.
Fair enough - thanks for the explanation! I'll probably leave it to some other folks who work more directly with llvm-mc than I do to weigh in on the design here, then.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D83725/new/
https://reviews.llvm.org/D83725
More information about the llvm-commits
mailing list