Open cpython-java opened 6 months ago
@llvm/issue-subscribers-backend-aarch64
Author: None (cpython-java)
Can try to reproduce this on llvm18? I dont see this issue on the latest code base.
Can try to reproduce this on llvm18? I dont see this issue on the latest code base.
I test here:https://godbolt.org/z/YndPMGGa4
isn't it a lastest code??thank you for you response!
Can try to reproduce this on llvm18? I dont see this issue on the latest code base.
I test here:https://godbolt.org/z/YndPMGGa4
isn't it a lastest code??thank you for you response!
Thanks. I had missed adding the -mattr=+zcm in the command line. I am able to reproduce the crash with that flag.
Can try to reproduce this on llvm18? I dont see this issue on the latest code base.
I test here:https://godbolt.org/z/YndPMGGa4 isn't it a lastest code??thank you for you response!
Thanks. I had missed adding the -mattr=+zcm in the command line. I am able to reproduce the crash with that flag.
I'm very sorry that I give a wrong cmd! It should be ./llc temp -mtriple=aarch64 -O=0 -mcpu=a64fx -mattr=+zcm
Reduced test case:
; ModuleID = '1360'
source_filename = "M"
@my_format_str_int = private unnamed_addr constant [4 x i8] c"%d\0A\00", align 1
define i32 @main() {
BB:
%A = alloca i16, align 8
store i64 1, ptr %A, align 4
%0 = call i16 @my_func_1(i16 -32768, i16 -32768)
%1 = zext i16 %0 to i32
%B = or i16 32767, %0
%2 = call i32 (ptr, ...) @printf(ptr @my_format_str_int, i32 %1)
store i16 %B, ptr %A, align 2
ret i32 0
}
declare i32 @printf(ptr, ...)
declare i16 @my_func_1(i16 %0, i16 %1)
We generate the following copy instruction
$w0 = COPY $wzr
which gets converted into
$x0 = ORRXrr $xzr, undef $noreg, implicit $wzr
after PostRAPseudoExpansion
. The $noreg that gets generated causes the crash.
The following block of code in AArch64InstrInfo.cpp is responsible for generating the above code:
if (Subtarget.hasZeroCycleRegMove()) {
// Cyclone recognizes "ORR Xd, XZR, Xm" as a zero-cycle register move.
MCRegister DestRegX = TRI->getMatchingSuperReg(
DestReg, AArch64::sub_32, &AArch64::GPR64spRegClass);
MCRegister SrcRegX = TRI->getMatchingSuperReg(
SrcReg, AArch64::sub_32, &AArch64::GPR64spRegClass);
// This instruction is reading and writing X registers. This may upset
// the register scavenger and machine verifier, so we need to indicate
// that we are reading an undefined value from SrcRegX, but a proper
// value from SrcReg.
BuildMI(MBB, I, DL, get(AArch64::ORRXrr), DestRegX)
.addReg(AArch64::XZR)
.addReg(SrcRegX, RegState::Undef)
.addReg(SrcReg, RegState::Implicit | getKillRegState(KillSrc));
There is no wzr
register in AArch64::GPR64spRegClass
and so the getMatchingSuperReg
call returns noreg for SrcRegX
Reduced test case:
; ModuleID = '1360' source_filename = "M" @my_format_str_int = private unnamed_addr constant [4 x i8] c"%d\0A\00", align 1 define i32 @main() { BB: %A = alloca i16, align 8 store i64 1, ptr %A, align 4 %0 = call i16 @my_func_1(i16 -32768, i16 -32768) %1 = zext i16 %0 to i32 %B = or i16 32767, %0 %2 = call i32 (ptr, ...) @printf(ptr @my_format_str_int, i32 %1) store i16 %B, ptr %A, align 2 ret i32 0 } declare i32 @printf(ptr, ...) declare i16 @my_func_1(i16 %0, i16 %1)
We generate the following copy instruction
$w0 = COPY $wzr
which gets converted into
$x0 = ORRXrr $xzr, undef $noreg, implicit $wzr
after
PostRAPseudoExpansion
. The $noreg that gets generated causes the crash.The following block of code in AArch64InstrInfo.cpp is responsible for generating the above code:
if (Subtarget.hasZeroCycleRegMove()) { // Cyclone recognizes "ORR Xd, XZR, Xm" as a zero-cycle register move. MCRegister DestRegX = TRI->getMatchingSuperReg( DestReg, AArch64::sub_32, &AArch64::GPR64spRegClass); MCRegister SrcRegX = TRI->getMatchingSuperReg( SrcReg, AArch64::sub_32, &AArch64::GPR64spRegClass); // This instruction is reading and writing X registers. This may upset // the register scavenger and machine verifier, so we need to indicate // that we are reading an undefined value from SrcRegX, but a proper // value from SrcReg. BuildMI(MBB, I, DL, get(AArch64::ORRXrr), DestRegX) .addReg(AArch64::XZR) .addReg(SrcRegX, RegState::Undef) .addReg(SrcReg, RegState::Implicit | getKillRegState(KillSrc));
There is no
wzr
register inAArch64::GPR64spRegClass
and so thegetMatchingSuperReg
call returns noreg forSrcRegX
So, it's a bug from the file "AArch64InstrInfo.cpp". I get it. Thank you for your explaination very much!!!
Reduced test case:
; ModuleID = '1360' source_filename = "M" @my_format_str_int = private unnamed_addr constant [4 x i8] c"%d\0A\00", align 1 define i32 @main() { BB: %A = alloca i16, align 8 store i64 1, ptr %A, align 4 %0 = call i16 @my_func_1(i16 -32768, i16 -32768) %1 = zext i16 %0 to i32 %B = or i16 32767, %0 %2 = call i32 (ptr, ...) @printf(ptr @my_format_str_int, i32 %1) store i16 %B, ptr %A, align 2 ret i32 0 } declare i32 @printf(ptr, ...) declare i16 @my_func_1(i16 %0, i16 %1)
We generate the following copy instruction
$w0 = COPY $wzr
which gets converted into$x0 = ORRXrr $xzr, undef $noreg, implicit $wzr
afterPostRAPseudoExpansion
. The $noreg that gets generated causes the crash. The following block of code in AArch64InstrInfo.cpp is responsible for generating the above code:if (Subtarget.hasZeroCycleRegMove()) { // Cyclone recognizes "ORR Xd, XZR, Xm" as a zero-cycle register move. MCRegister DestRegX = TRI->getMatchingSuperReg( DestReg, AArch64::sub_32, &AArch64::GPR64spRegClass); MCRegister SrcRegX = TRI->getMatchingSuperReg( SrcReg, AArch64::sub_32, &AArch64::GPR64spRegClass); // This instruction is reading and writing X registers. This may upset // the register scavenger and machine verifier, so we need to indicate // that we are reading an undefined value from SrcRegX, but a proper // value from SrcReg. BuildMI(MBB, I, DL, get(AArch64::ORRXrr), DestRegX) .addReg(AArch64::XZR) .addReg(SrcRegX, RegState::Undef) .addReg(SrcReg, RegState::Implicit | getKillRegState(KillSrc));
There is no
wzr
register inAArch64::GPR64spRegClass
and so thegetMatchingSuperReg
call returns noreg forSrcRegX
So, it's a bug from the file "AArch64InstrInfo.cpp". I get it. Thank you for your explaination very much!!!
Oh no. I was just explaining why the crash is happening. I dont know much about the zcm extension to comment on whether we are doing something incorrect here. Someone with a better understanding will need to comment on this.
description
when i use 'llc' to translate an IR, crash happened. I don't know whether it's a bug of 'llc' and want to be sure about it.
thank you for your help!
ir
cmd
./llc temp -mtriple=aarch64 -O=0 -mcpu=a64fx -mattr=+zcm
(llc
->17.0.4
)error info