[cfe-dev] Help with register allocation for undef inputs to inline asm

[Eli Friedman via cfe-dev]

Ignore undef for a moment.  The first question to ask here is, is it legal for two different inputs to an inline asm to be assigned the same register?  Consider, for example:

void func()
{
    unsigned long long b = 99, n = 99;
    __asm__ volatile ("# %0, %1" :: "r"(n), "r"(b));
}

The answer here is yes, we can assign them to the same register, since they have the same value.  Clang and gcc agree here.

Now consider the case of an undef input.  Given the behavior we've established, you're basically asking, "can we add an exception that undef is never equal to 99?".

-Eli

> -----Original Message-----
> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of David Spickett via
> cfe-dev
> Sent: Thursday, July 8, 2021 8:36 AM
> To: cfe-dev at lists.llvm.org Developers <cfe-dev at lists.llvm.org>
> Subject: [EXT] [cfe-dev] Help with register allocation for undef inputs to inline
> asm
> 
> (since this is inline asm I'm sending this to cfe-dev, though it
> includes llvm's logic)
> 
> I've been looking at this bug report:
> https://bugs.llvm.org/show_bug.cgi?id=50647
> (the initial report is for ARM but I've found it applies to any architecture)
> 
> Where an undef input to an inline asm statement isn't assigned its own
> register and overlaps a second input value. Here's a minimal version
> of it:
> void func(unsigned long long n)
> {
>     unsigned long long b;
>     n = 99;
> 
>     __asm__ volatile (
>         "add %[_b], %[_b], %[_b] \n\t" // Assigned register X
>         "add %[_n], %[_n], %[_n] \n\t" // Also assigned register X
>         :
>         : [_n] "r" (n), [_b] "r" (b)
>     );
> }
> 
> Godbolt: https://godbolt.org/z/bro9hde46
> 
> This produces an inline asm statement in IR where the input for "b" is undef.
> tail call void asm sideeffect "add $1, $1, $1 \0A\09add $0, $0, $0
> \0A\09", "r,r"(i64 99, i64 undef) #2, !dbg !22, !srcloc !23
> 
> This makes sense and I can see intuitively why you wouldn't assign a
> unique register to an undef value. It has no value after all, it could
> be anything including the same value as the other input. I tracked
> this decision down to somewhere in the VirtRegRewriter pass but I
> haven't been able to pin down the exact place yet.
> 
> My question is:
> Would making an exception here for the inline asm case make sense? Or
> is this an instance of undef values gives you undef results, in a way
> that we would be happy to keep. (FWIW gcc does assign unique registers
> in this case)
> 
> Thanks,
> David Spickett.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev