llvm dev - Jan 2021 - RFC: Adding HLASM Parsing support for inline asm blocks (1st parameter) to LLVM.

Hi All,

We plan introducing minimal HLASM syntax support for inline asm blocks to LLVM
for z/OS. The minimal syntax support will be for the 1st parameter of the inline
asm block.

To do this, we plan on the following:


1. Create a new HLASMAsmParser class which inherits from the base AsmParser
class (defined in AsmParser.cpp)
2. Return this instance of the HLASMAsmParser, in the createMCAsmParser
function, when we're on z/OS and when we have an appropriate assembler
dialect defined in the target dependent (SystemZ) MCAsmInfo instance
3. Make functions in the base AsmParser class as virtual and override these
within the HLASMAsmParser class wherever appropriate.
4. Add in private functions to the HLASMAsmParser class as needed.

Would this be a suitable approach to move forward with? A very very simple
implementation is provided in this draft patch here
(https://reviews.llvm.org/D94317). There mostly will be other changes as well
but these would mostly go into the SystemZAsmParser class.

We did examine some other approaches. They are listed below and reasons are
provided as to why we did not think they were the best.

1. We thought about adding a new inline asm dialect right from the front end,
and setting this in the AsmParser, and using it a toggle to parse HLASM inline
asm statements. However, we believed this was not needed because, even for
inline asm on z/OS, the "format" of the inline asm statement is still
a gnu asm statement (with the same input operands, output operands, clobbers
etc.), and thus, we felt it would be sufficient to just set the AssemblerDialect
field in the SystemZMCAsmInfo instance appropriately.

2. We also examined adding plain private functions to the AsmParser class for
dealing with processing inline asm on z/OS. The disadvantage of this, would be
that these functions would be of non-use to any non-z/OS target(s). Similarly,
adding any pure virtual functions to the base MCAsmParser class and overriding
them in AsmParser would also have the same disadvantage.

Feedback and other opinions are greatly welcome! 

Thanks and Regards,
Anirudh Prasad