codegen crash with inline asm

Quuxplusone commented 11 years ago


Bugzilla Link	PR14393
Status	NEW
Importance	P enhancement
Reported by	Rafael Ávila de Espíndola (rafael@espindo.la)
Reported on	2012-11-20 15:07:35 -0800
Last modified on	2019-12-23 21:28:39 -0800
Version	trunk
Hardware	PC Linux
CC	craig.topper@gmail.com, echristo@gmail.com, efriedma@quicinc.com, emvv@mail.ru, konstantin.belochapka@sony.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, pawel@32bitmicro.com, spatel+llvm@rotateright.com, viswabramana.rajesh@gmail.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Reported by rajesh viswabramana on llvmdev, I just converted the test to IL:

-------------------------------------------
target triple = "i386-unknown-linux-gnu"

define double @func1() {
entry:
  %0 = tail call double asm "", "=r,0,~{dirflag},~{fpsr},~{flags}"(double undef)
  ret double %0
}
--------------------------------------------

$ ./bin/llc test.ll
llc:
/home/espindola/llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:383:
void getCopyToParts(llvm::SelectionDAG &, llvm::DebugLoc, llvm::SDValue,
llvm::SDValue *, unsigned int, llvm::EVT, const llvm::Value *, ISD::NodeType):
Assertion `(PartVT.isInteger() || PartVT == MVT::x86mmx) && ValueVT.isInteger()
&& "Unknown mismatch!"' failed.

Quuxplusone commented 11 years ago

Well, it really shouldn't be done that way, but we shouldn't crash either.

Quuxplusone commented 11 years ago

I found similar bug already reported, Closed

http://llvm.org/bugs/show_bug.cgi?id=8363

As per last comments in bug 8363,

Eric Christopher 2011-06-29 13:16:29 CDT
This appears to be fixed from the front end side of things.

But issue still present.

Quuxplusone commented 11 years ago

There isn't any possible way we can generate sane code for this; "r" means an integer register, and a 64-bit value can't fit into a 32-bit register. That said, both clang and the LLVM backend should be taught to generate a proper error message.

Quuxplusone commented 11 years ago

I tried same code with gcc on arm with 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

Quuxplusone commented 11 years ago

@ Eli Friedman
 Could you please elobarate why generated code will be sane code if handled ?
 Is gcc also shouldn't handle this case ?
 Is there some specific reason for not handling this in llvm ?

Quuxplusone commented 11 years ago

See the discussion on llvmdev; gcc's behavior is weird, but consistent in a usable way for this particular case.

Quuxplusone commented 11 years ago

Yet another testcase -target armv7-linux-gnueabihf:
void check_vect (void)
{
    long long a = 0;
    asm ("vorr %P0" :"=w" (a) : "0" (a));
}

Quuxplusone commented 4 years ago

https://reviews.llvm.org/D35587 proposed a fix but hasn't been touched for years

Quuxplusone / LLVMBugzillaTest

codegen crash with inline asm #14408