Wilco Dijkstra <[email protected]> writes: > Hi Richard, > >> Why do we need to emit .eh_frame CFI for register state that is not >> preserved by the base PCS, and thus not preserved across exception >> edges? When would the extra register state be required? > > During debugging for example - without correct unwind info you cannot > display locals that were callee-saved by a vector math function.
Isn't that going to happen anyway though? Vector PCS functions preserve the whole of Q8-Q15, but the CFI will only describe a 64-bit save. > We could add such a feature, however I don't believe it would reduce the > unwind info all that much since vector functions are not that common. > There was a discussion about designing a more compact non-asynchronous > unwind format which would give far larger gains [1]. However you would > still need to emit asynchronous Dwarf unwind info for debugging in addition > to SFrame for those who want fast backtraces with kernel support... > > [1] > https://discourse.llvm.org/t/rfc-improving-compact-x86-64-compact-unwind-descriptors/47471 Thanks, I'll have a look later. I think the bug in the PR is related to the pair-fusion pass though. It isn't correctly preserving RTX_FRAME_RELATED_P when combining two stores, one frame-related and one not. I'll update the PR in a sec. Richard
