[PATCH] D45164: [MC] Change AsmParser to leverage Assembler during evaluation

[Nirav Dave via Phabricator via llvm-commits]

niravd added a comment.

It's documented that we output (.s) and I believe this is specifically so we are compatible with assemblers without sufficient preprocessor support. It may be reasonable to add a (.S) output but as it's been pointed out the textual semantics of the preprocessor are not suited for this and 
error/warnings quality would almost certainly degrade.

All of the inputs I've seen are .S files; no inline assembly. They've been are limited to .data blocks where there's no ambiguity about sizes (This is what the current patch handles).  The gnu assembler does a bit more and handles assembler-dependent preprocessor expressions when the intermediate artifact's sizes are explicitly known (i.e. data and instructions of known size), but it's not clear if the extra capabilities are ever used or needed (The closest I've found is a case where a .fill directive was used to do pad a block with nops but that's utterable in our assembly output currently). Regardless, gas's support rules out all of the tricky cases James mentioned so textual output is reasonable as a output artifact (at least as reasonable as what we have currently).

I have not found any documentation giving guarantees about the correspondence between output types, but it seem natural to me that direct object generation may be more permissive than compilation through assembly hence this patch. There already appear to be additional restrictions in the AsmStreamer (e.g. dwarf CUID) over the ObjectStreamer so this isn't a new thing.

That said, modulo the extra bookkeeping costs for textual assembly additional checks for incomplete assemblers, there's no real reason why MCAsmStreamer and MCObjectStreamer are separate structures and it would be good to eventually merge them.


Repository:
  rL LLVM

https://reviews.llvm.org/D45164