[PATCH] D134866: [WinEH] Fix PreISel intrinsics in funclet catchret.dest blocks

Stefan Gränitz via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 29 03:30:57 PDT 2022


sgraenitz added a comment.

Adding extra debug output <https://github.com/weliveindetail/llvm-project/commit/ec50c9eb677875535c7475b528f01480dbb2b9af> showed that the respective block 0x719c170 is referencing the funclet pad 0x719bed0 from another group, while the one in its own group is Null. That's the one we compare with in `FuncletBundleOperand == FuncletPad`. This looks like invalid state to me:

  FuncletPadBB: 0x0000000007198c10
    FuncletPad: 0x0000000000000000
            BB: 0x0000000007198c10 -> OB_funclet: 0x0000000000000000
            BB: 0x000000000719c170 -> OB_funclet: 0x000000000719bed0 ---+
  FuncletPadBB: 0x000000000719b9b0                                      |
    FuncletPad: 0x0000000000000000                                      |
  FuncletPadBB: 0x000000000719bca0                                      |
    FuncletPad: 0x000000000719bed0 <------------------------------------+
            BB: 0x000000000719bca0 -> OB_funclet: 0x000000000719bed0

It appears that EH funclet coloring is responsible for this. Output from `--debug-only=winehprepare-coloring` was:

  Coloring funclets for test_catch_with_objc_intrinsic
  Visiting entry, entry
    Assigned color 'entry' to block 'entry'.
  Visiting catch.dispatch, entry
    Assigned color 'catch.dispatch' to block 'catch.dispatch'.
  Visiting catch, catch.dispatch
    Assigned color 'catch' to block 'catch'.
  Visiting catchret.dest, entry
    Assigned color 'entry' to block 'catchret.dest'. <--- Shouldn't this have color 'catch'?
  Visiting eh.cont, entry
    Assigned color 'entry' to block 'eh.cont'.
  Visiting eh.cont, entry

I managed to hack it so that `catchret.dest` ends up in the correct group, but it breaks numerous tests: https://github.com/weliveindetail/llvm-project/commit/d678c7aafc75435147017bf999d54b1be5262db4

Not sure if adding the funclet pad condition as proposed in this patch is the best solution, but it's not breaking any test and it's effective in avoiding the truncation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134866



More information about the llvm-commits mailing list