[PATCH] D95444: Allow GNU inline asm using target-specific dialect variant

Anirudh Prasad via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 5 09:43:37 PST 2021


anirudhp added a comment.

In D95444#2542739 <https://reviews.llvm.org/D95444#2542739>, @rnk wrote:

> - Inline asm will now be parsed into MCInstructions using the HLASM dialect, and then the MCInstructions will either be directly emitted or textually emitted in the GNU dialect

Yes this is the idea behind this patch and a series of subsequent patches (main RFC about introducing HLASM syntax <https://lists.llvm.org/pipermail/llvm-dev/2021-January/147686.html>):

> That seems reasonable, but I wonder if the change should be in the frontend. Clang actually supports mixing GCC and MSVC inline asm in the same translation unit, and it uses the dialect flag in the IR to control this (I think). This is important if you want to support LTO between two TUs that use GCC and HLASM. Maybe there is exactly zero inline asm that uses GCC-style asm for SystemZ, so maybe this isn't a concern, but I thought I'd ask.

(I'm also commenting on this since I will be working on putting up some of the patches pertaining to the HLASM syntax soon.).

Would you please be able to expand on this a bit more? I don't believe we will allow intermixing of gnu asm and hlasm in an inline asm context anyway. Since the standard format of an HLASM statement (atleast the support that we're adding for it) has the same format of a gnu asm statement (with respect to its inputs, outputs, clobbers etc.). The dialect's "rules" comes into play while parsing the inline asm instructions into corresponding MCInst (like you mentioned) and have them emitted (either to object file or assembly file). The parsing of the input operands, output operands, clobbers remain unchanged. My apologies if I haven't seen your point you're trying to make right away.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95444/new/

https://reviews.llvm.org/D95444



More information about the llvm-commits mailing list