dpaoliello wrote: > Any further thoughts on splitting unwind info, as we discussed in #110338?
Unfortunately, this isn't going to work. @pmsjt informs me that we can't have epilogs in chained unwind tables, since they are only for additional savereg codes. Using the "assume terminator is 1-byte" trick allows mixed terminators in a single function, so the only other place we'd need it is for functions with more than 256 unwind codes, where the dev will have to split their functions manually. Not sure if I should add a heuristic into the pass to downgrade to v1 if there *might* be too many codes? > Have you tried to figure out how frequently LLVM generates non-compliant > epilogues? Are you planning changes to prologue/epilogue emission to avoid > those cases? >From there existing tests, there was only one non-compliant epilog: https://github.com/llvm/llvm-project/blob/818bca820ffd3e30fbd3852da0436c24ff15f8a3/llvm/test/CodeGen/X86/avx512-regcall-Mask.ll#L952-L958 But yes, my current plans are: 1. Add a flag/attribute to require Unwind v2 (i.e., raise an error in my new pass instead of reverting to v1), this is equivalent to the `/d2epilogunwindrequirev2` MSVC flag). 1. Compile various things and see what gets rejected, then fix each issue. If I observe cases where the offset is too large, my plan is to modify the pass to move blocks closer to the end of the function if they are beyond some heuristic (basically guessing what the offset would be). https://github.com/llvm/llvm-project/pull/129142 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
