Do we have some broad overview of the approach and the algorithm? It'd be a good idea put something like this in the description and eventually the commit message. (I searched for LLVM complex RFCs, buy couldn't find anything useful).

Revert to a previous version, which scanned all the memory
accesses in a block. Add a testcase showing why it's necessary.

Fixed a bootstrap failure, there was a missing check for end iterator.

Should these lists contain only source tree headers or also generated header files? I'm not seeing arm_mve.h, for example.

Updated to exclude unreachable blocks.

In D114545#3428728, @omjavaid wrote:

Hi I have temporarily reverted this change as it has caused LLVM buildbot failures with failing fuzzer-threaded.test with clang crashing over an assertion failure in llvm/lib/CodeGen/CFIFixup.cpp. Kindly look into it. Thanks
.

In D114545#3421297, @MaskRay wrote:

Looks great! Thanks again for the hard work! And sorry again for being so slow to get to this important pass :-(

In D114545#3409903, @MaskRay wrote:

"layout order" seems to suggest the linear placement order.

That's right, it's the order of increasing instruction addresses, corresponding to the basic block layout and the order of instructions in the basic block.

Rebased.

Rebased

Updated on top of latest main, will commit it the following days, based on previous
acceptance, as it contains no non-trivial changes.

Updated on top of latest main, will commit it the following days, based on previous
acceptance, as it contains no non-trivial changes.

Updated on top of latest main and on top of D121017
Now https://bugs.chromium.org/p/chromium/issues/detail?id=1302998 should be fixed.

Ping.

PIng?

Brought forward, emitting epilogue would no be correct without this patch. A little bit of tests moved to the epilogues patch, no other changes.

Committing this change caused failures in the asan/hwasan regression tests. The reason was that emitting unwind info
in epilogues caused the unwind information in case like below:

foo:
  ...
  CSR saves
  ...
  CSR restores
  ret
L:
  ...
  b <somewhere>

to no longer be accidentally correct for the region starting at L. That could be a miscompilation
if a throwing call somehow ends up in that region.