llvm dev - Jun 2021 - RFC: New mechanism for hard register operands to inline asm

Hi All,

We wanted to bring up the possibility of introducing a new inline asm constraint
for all targets. This new constraint is meant to be used as a replacement for
the register asm construct. Part of the motivation behind this proposal is to
come up with something that is a bit nicer and more obvious to use. The new
inline asm constraint would be as follows:

{“<register-name>”} (operand name) ...

The constraint will try to tie the particular inline asm operand to a specific
register.

This is also proposed as an RFC in the GCC mailing lists
(https://gcc.gnu.org/pipermail/gcc/2021-June/236269.html). We would ideally like
to maintain consistency with GCC.

We have an example in the IBM Z kernel source code, where we believe an
introduction of such an inline asm constraint would be beneficial.

Example: turning this source:
```
int diag8_response(int cmdlen, char *response, int *rlen)
{
        register unsigned long reg2 asm ("2") = (addr_t) cpcmd_buf;
        register unsigned long reg3 asm ("3") = (addr_t) response;
        register unsigned long reg4 asm ("4") = cmdlen | 0x40000000L;
        register unsigned long reg5 asm ("5") = *rlen; /* <-- */
        asm volatile(
                "       diag    %2,%0,0x8\n"
                "       brc     8,1f\n"
                "       agr     %1,%4\n"
                "1:\n"
                : "+d" (reg4), "+d" (reg5)
                : "d" (reg2), "d" (reg3), "d"
(*rlen): "cc");
        *rlen = reg5;
        return reg4;
}
```

into this:

```
int diag8_response(int cmdlen, char *response, int *rlen)
{
        unsigned long len = cmdlen | 0x40000000L;

        asm volatile(
                "       diag    %2,%0,0x8\n"
                "       brc     8,1f\n"
                "       agr     %1,%4\n"
                "1:\n"
                : "+{r4}" (len), "+{r5}" (*rlen)
                : "{r2}" ((addr_t)cpcmd_buf), "{r3}"
((addr_t)response), "d" (*rlen): "cc");
        return len;
}
```

Why we believe the introduction of this new “hard register” inline asm
constraint to be useful?

1. It is more flexible than the register asm construct since a user does not
need to be concerned with which registers are previously mapped to which
variable(s).
2. The documentation of the register asm construct (https:/
/gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html) specifies that
function calls might clobber registers assigned with "register asm".
Using this new inline asm constraint ensures that the operand is assigned to a
particular register only in the context of the inline asm call.
3. One register asm variable cannot be used for 2 different inline assembly
statements if the value is expected in different hard registers.

We are very interested in hearing opinions on the above proposal!

Thanks and Best Regards,
Anirudh Prasad

On Tue, Jun 22, 2021, 08:54 Anirudh Prasad via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi All,
>
> We wanted to bring up the possibility of introducing a new inline asm
> constraint for all targets. This new constraint is meant to be used as a
> replacement for the register asm construct. Part of the motivation behind
> this proposal is to come up with something that is a bit nicer and more
> obvious to use. The new inline asm constraint would be as follows:
>
> {“<register-name>”} (operand name) ...
>
This is somewhat similar to Rust's new inline assembly syntax:
https://github.com/rust-lang/rfcs/blob/master/text/2873-inline-asm.md#explicit-register-operands

We are very interested in hearing opinions on the above proposal!


I think this is a good idea!

Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210622/817cb616/attachment.html>

On Tue, Jun 22, 2021 at 11:54 AM Anirudh Prasad via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi All,
>
> We wanted to bring up the possibility of introducing a new inline asm
> constraint for all targets. This new constraint is meant to be used as a
> replacement for the register asm construct. Part of the motivation behind
> this proposal is to come up with something that is a bit nicer and more
> obvious to use. The new inline asm constraint would be as follows:
>
> {“<register-name>”} (operand name) ...
>
> The constraint will try to tie the particular inline asm operand to a
> specific register.
>
> This is also proposed as an RFC in the GCC mailing lists (
> https://gcc.gnu.org/pipermail/gcc/2021-June/236269.html). We would
> ideally like to maintain consistency with GCC.
>
Sounds good --  if GCC also implements it. Behind the scenes, Clang
effectively already implements this proposal -- the register-asm-variables
are just a strange frontend spelling for hard register constraints. They do
nothing else, and in particular, they do NOT necessarily live in that
register other than when being passed to/from an inline asm. So, we'd be
adding a second (more obvious) spelling to do the exact same thing we
already implement. IMO it would not be worth it if this new syntax was
unique to Clang, but is if both clang and gcc implement it.

Why we believe the introduction of this new “hard register” inline
asm
> constraint to be useful?
>
> 1. It is more flexible than the register asm construct since a user does
> not need to be concerned with which registers are previously mapped to
> which variable(s).
> 2. The documentation of the register asm construct (https:/ /
> gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html) specifies that
> function calls might clobber registers assigned with "register
asm". Using
> this new inline asm constraint ensures that the operand is assigned to a
> particular register only in the context of the inline asm call.
>
This advantage doesn't apply to Clang, because the asm-register variables
are already assigned to the named register only in the context of an inline
asm call.

3. One register asm variable cannot be used for 2 different inline
assembly
> statements if the value is expected in different hard registers.
>
> We are very interested in hearing opinions on the above proposal!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210622/bc8a0343/attachment.html>

On 22/06/2021 16:54, Anirudh Prasad via llvm-dev wrote:
> Hi All,
> 
> We wanted to bring up the possibility of introducing a new inline asm
constraint for all targets. This new constraint is meant to be used as a
replacement for the register asm construct. Part of the motivation behind this
proposal is to come up with something that is a bit nicer and more obvious to
use. The new inline asm constraint would be as follows:
> 
> {“<register-name>”} (operand name) ...
> 
> The constraint will try to tie the particular inline asm operand to a
specific register.
> 
> This is also proposed as an RFC in the GCC mailing lists
(https://gcc.gnu.org/pipermail/gcc/2021-June/236269.html). We would ideally like
to maintain consistency with GCC.
It looks as if you're proposing a new representation of *C* inline 
assembly, not LLVM IR inline assembly.  As such, the only LLVM component 
that need to be modified to support it is Clang.  If you post this on 
the Clang developers list, you are likely to get feedback from the right 
set of people.

David