Open WillClinger opened 8 years ago
I don't think I ever pushed a version of the ARMv7 register assignments that used sp
for any unconventional purpose, and I haven't been able to reproduce this bug without changing the register assignments to use sp
as STKP
, so I'm downgrading the priority of this issue and changing the milestone.
I'm leaving this issue open because I don't understand why we can't use sp
as STKP
. It's possible that the bug is unrelated to the register assignment, and just happens to show up with the non-standard register assignment.
This looks like it has been a latent bug in the ARM code generator, but I didn't find it until I tried to free up another ARM register by using
sp
asSTKP
.The newly aggressive register assignment seemed to be working fine until a segfault occurred while compiling
27.sld
. That library just imports the R6RS version, and the segfault occurred while reading compiled code for the R6RS version. The segfault is more easily reproduced by evaluating(string->number "1403580.0")
. Here is the relevant machine code:The code generated by
cant.mul/bnv
assumedSTKP
is a general register that can be used as a scratch register provided it is saved and restored. Now thatSTKP
issp
, however, we must maintain the multiple-of-4 stack alignment at all times.But there's another problem: The conditional branch at 0xb660c388 above can skip over the instruction that restoresSTKP
, regardless of whetherSTKP
issp
. That conditional branch wasn't generated directly bycant.mul/bnv
, so it must have been added by the optimizer. That probably means there's a bug in the ARM machine code optimizer as well.Or maybe the optimizer was correct untilSTKP
becamesp
. Either way, it's a bug now.No, the optimizer's okay. The conditional branch won't be executed if
sp
has been clobbered. So it looks as though this may just be a violation of thesp
invariant, with processor-dependent behavior.