[llvm-dev] RFC: Adding HLASM Parsing support for inline asm blocks (1st parameter) to LLVM.
Anirudh Prasad via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 8 10:04:32 PST 2021
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
More information about the llvm-dev
mailing list