While writing a regression test for #8 I have spent some time trying to understand why I cannot clobber r4 via __asm__ while clobbering r5 - r10 works fine. The code was like this:
define i16 @pops_7_regs() nounwind {
; CHECK-LABEL: pops_7_regs
call void asm sideeffect "", "~{r4},~{r5},~{r6},~{r7},~{r8},~{r9},~{r10}"()
ret i16 42
; CHECK: jmp __mspabi_func_epilog_7
; CHECK-NOT: ret
; CHECK: -- End function
}
llc was silently ignoring ~{r4} constraint, then generating otherwise correct epilogue (for r5 - r10 being clobbered) and replacing it with jmp __mspabi_func_epilog_6. The fix was literally two-byte-size: replace r4 register name with fp.
While llc is internal tool for LLVM developers, it still may be worth implement some checks where it is trivial to do.
For both MSP430 and X86, the register names are checked by clang and are NOT checked by llc, so this is consistent behavior.
The other problem with particularly the MSP430 backend was that clang does accept r4 as a valid register name passing it through as r4. So, now it is a user-facing issue, as well.
My proposal would be to implement some assertions, at first, where it is most trivial and makes any sense. IMO, these should be specifically assertions and not some neat error messages such as well-known "undefined symbol" errors, otherwise it would implicitly suggest we have full constraint validation, which would be not true, at least for the first time.
While writing a regression test for #8 I have spent some time trying to understand why I cannot clobber
r4
via__asm__
while clobberingr5
-r10
works fine. The code was like this:llc
was silently ignoring~{r4}
constraint, then generating otherwise correct epilogue (forr5
-r10
being clobbered) and replacing it withjmp __mspabi_func_epilog_6
. The fix was literally two-byte-size: replacer4
register name withfp
.While
llc
is internal tool for LLVM developers, it still may be worth implement some checks where it is trivial to do.For both
MSP430
andX86
, the register names are checked byclang
and are NOT checked byllc
, so this is consistent behavior.The other problem with particularly the MSP430 backend was that
clang
does acceptr4
as a valid register name passing it through asr4
. So, now it is a user-facing issue, as well.My proposal would be to implement some assertions, at first, where it is most trivial and makes any sense. IMO, these should be specifically assertions and not some neat error messages such as well-known "undefined symbol" errors, otherwise it would implicitly suggest we have full constraint validation, which would be not true, at least for the first time.