llvm dev - Nov 2012 - [LLVMdev] Extended Inline asm with double data type crashes clang

On Thu, Nov 22, 2012 at 4:14 AM, rajesh viswabramana
<viswabramana.rajesh at gmail.com> wrote:
> Hi all,
>
> I tried same code on gcc for arm(hard float),
>
> double f2 ()
> {
> double x = 10.0;
>
> asm ("" : "=r" (x) : "0" (x));
> return x;
> }
>
>> arm-linux-gnueabi-gcc -S -mhard-float pr39058.c -O2
>
> Generates proper code,
>     mov    r3, #0
>     mov    r2, #0
>     movt    r3, 16420
>     fmdrr    d0, r2, r3
>     bx    lr
>
> But llvm crashes, If data type is "double", register type is
"int".
> Any comments why does llvm currently handle this case ?
"r" is supposed to be a single register, not a register pair; the fact
that gcc accepts this is probably an accident.  clang should reject
this code (without crashing, of course).

-Eli

> "r" is supposed to be a single register, not a register pair; the
fact
> that gcc accepts this is probably an accident.  clang should reject
> this code (without crashing, of course).
I'm not quite convinced by this. On AArch64, GCC supports the %H, %Q
and %R operand modifiers which very explicitly deal with a pair of
64-bit registers. These are intended to be used with the 'r'
constraint (I asked, specifically because there wasn't a corresponding
"register-pair" constraint).

It could just be the new port and no-one's noticed the rules have been
broken yet, of course. So we could take the high road, but it's a
little unclear who we should go whinging to that GCC is breaking the
rules of the GCC-specific inline assembly syntax.

Tim.

On Thu, Nov 22, 2012 at 1:19 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
>> "r" is supposed to be a single register, not a register pair;
the fact
>> that gcc accepts this is probably an accident.  clang should reject
>> this code (without crashing, of course).
>
> I'm not quite convinced by this. On AArch64, GCC supports the %H, %Q
> and %R operand modifiers which very explicitly deal with a pair of
> 64-bit registers. These are intended to be used with the 'r'
> constraint (I asked, specifically because there wasn't a corresponding
> "register-pair" constraint).
>
> It could just be the new port and no-one's noticed the rules have been
> broken yet, of course. So we could take the high road, but it's a
> little unclear who we should go whinging to that GCC is breaking the
> rules of the GCC-specific inline assembly syntax.
Hmm... it isn't completely without precedent to have a constraint
which refers to multiple registers (like the x86 "A" constraint), but
it doesn't seem like something which can be done generically: what
"pairs" would we allow for "r" on e.g. x86?

Of course, while writing this, I just realized this is a variant of a
bug which has been discussed on llvm-commits: PR13622.  And gcc
actually does implement pairs on x86; I think the choice of registers
is based on some internal register allocator sequence.  And gcc also
knows how to allocate register triplets on x86 (though I have no clue
how you would use them). :)

Ugh, I wish gcc's inline asm extension didn't expose so much of the
insanity of gcc internals.

-Eli