[PATCH] D125536: [MC] [MCWin64EH] Try writing an ARM64 "packed epilog" even if the epilog doesn't share opcodes with the prolog

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 13 16:34:17 PDT 2022


efriedma added inline comments.


================
Comment at: llvm/lib/MC/MCWin64EH.cpp:656
 
   info->EpilogMap.clear();
   return Offset;
----------------
This call to `EpilogMap.clear()` tripped me up in trying to understand the reasoning behind the rest of the changes in this patch.  There are three cases here:

1. Unpacked epilogues
2. Packed epilogue reusing the prologue
3. Packed epilogue not reusing the prologue.

In the "Packed epilogue reusing the prologue" case, we clear EpilogMap; in the other cases, we don't.

Maybe the logic here could be a bit more explicit?  Like maybe instead of clearing EpilogMap(), add checks in the caller in the two places it matters.


================
Comment at: llvm/lib/MC/MCWin64EH.cpp:990
     MCSymbol* MatchingEpilog =
       FindMatchingEpilog(EpilogInstrs, AddedEpilogs, info);
     if (MatchingEpilog) {
----------------
Possible followup optimization: we could teach FindMatchingEpilog to look at the prologue.  (Not sure how frequently that would trigger.)


================
Comment at: llvm/lib/MC/MCWin64EH.cpp:1029
     // FIXME: We should share epilog codes across epilogs, where possible,
     // which would make this issue show up less frequently.
     if (CodeWords > 0xFF || EpilogCount > 0xFFFF)
----------------
Is the fixme about sharing epilog codes fixed?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125536/new/

https://reviews.llvm.org/D125536



More information about the llvm-commits mailing list