[lldb][swift] Increase number of Rows inspected when unwinding async functions #10698
Conversation
|
@swift-ci test |
felipepiovezan
force-pushed
the
felipe/tweak_unwind_rows
branch
from
9c8ca42 to
8137dee
Compare
|
@swift-ci test |
|
I spoke in DM with Felipe about one small concern, the AAPCS ABI has 10 general purpose registers marked callee-preserved, and 8 floating point registers. If they're stored with STP instructions, that means we can have the initial unwind state row, two standard prologue rows, and then 9 rows of registers being stored to stack before the stack pointer is copied into the frame pointer, worst possible case? |
…functions We were overly conservatives in our initial estimations: if callee saved registers are used, they are usually spilled first, increasing the number of rows in the prologue. This also revealed a bug in computing the offset of a vector iterator: ``` - int row_idx = fp_locs.end() - it; + int row_idx = it - fp_locs.begin(); ``` Testing this is unfortunately difficult: a way of forcing register spilling is required. For now, this commit tweaks one of the existing tests in a way that seems to reliably spill more registers, but there are no guarantees this will continue to be the case. Other testing mechanisms need to be created.
felipepiovezan
force-pushed
the
felipe/tweak_unwind_rows
branch
from
8137dee to
00ccdc2
Compare
Based on this conversation, I've pushed an update to increase this threshold to 12, and add some sub-optimal testing. As mntioned in the commit message, I'll need to investigate reliable ways of forcing register spilling as a follow up |
|
@swift-ci test |
|
Github is not showing the windows CI link, but it is running here: https://ci-external.swift.org/job/apple-llvm-project-pull-request-windows/2071/ |
|
The windows CI finished and was successful, but somehow github is not showing that.. |
|
@swift-ci test windows platform |
…functions (#10698) We were overly conservatives in our initial estimations: if callee saved registers are used, they are usually spilled first, increasing the number of rows in the prologue. This also revealed a bug in computing the offset of a vector iterator: ``` - int row_idx = fp_locs.end() - it; + int row_idx = it - fp_locs.begin(); ``` Testing this is unfortunately difficult: a way of forcing register spilling is required. For now, this commit tweaks one of the existing tests in a way that seems to reliably spill more registers, but there are no guarantees this will continue to be the case. Other testing mechanisms need to be created. (cherry picked from commit 3307906)
We were overly conservatives in our initial estimations: if callee saved
registers are used, they are usually spilled first, increasing the
number of rows in the prologue.
This also revealed a bug in computing the offset of a vector iterator:
Testing this is unfortunately difficult: a way of forcing register
spilling is required. For now, this commit tweaks one of the existing
tests in a way that seems to reliably spill more registers, but there
are no guarantees this will continue to be the case. Other testing
mechanisms need to be created.