In D73739#2278496, @rahmanl wrote:

Although I can definitely work with you to diagnose any potential issues on ARM64, I suggest we don't write tests for this patch before the base feature is well-tested.
(On related note, a recent commit (rG157cd93b48a9) limited -fbasic-block-sections to X86.).

@rahmanl Have you had a chance to run your added test on ARM64 as another itanium C++ ABI target to make sure it works properly? Having testing there is fine as a follow-up but wanted to make sure we're in agreement here. Otherwise changes LGTM, please let @MaskRay have a chance to provide any additional feedback.

Thanks @asbirlea!

Rebase #2

Remove unnecessary period

Fix merge issues with comment, updated description to include benefit we see from this change. Thanks @asbirlea for the quick review!

Rebase

These changes will also apply to other Itanium C++ ABI targets (arm32/arm64/RISCV etc.) so adding testing for at least another target is good. Trying this out for arm64 hits an ICE here:

case TargetOpcode::EH_LABEL:
  if (MBB.isBeginSection() && MBB.isEHPad() &&
      ((*std::prev(MI.getIterator())).getOpcode() ==
       TargetOpcode::CFI_INSTRUCTION)) {

which is worth following up on.

In D73739#2264518, @MaskRay wrote:

Taking a closer look at the test (haven't delved into the code yet): the PIC vs non-PIC difference of .gcc_exception_table looks strange.
.gcc_except_table (please also test its section flags "a") has an absolute relocation referencing main.2. This is not good. In all targets (except RISC-V -mno-relax), .gcc_except_table is a relocation-free section.

In D73739#2261537, @snehasish wrote:

Once this patch is in we can look into splitting ehpads out though I'm more inclined to enhance the static profile count mechanism to account for ehpads appropriately rather than adding a new flag to MFS.

On this front, is there a specific reviewer that we're waiting for here to get this change through?

Looking at https://bugs.llvm.org/show_bug.cgi?id=36578:
Andrew Kelley 2019-08-11 09:00:59 PDT
I'm no longer subscribed to this bug report. I've come to the conclusion that LLVM's coroutine API is not worth using, and resorting to implementing coroutines directly in the frontend.

I think with this alongside the recently committed MachineFunctionSplitter (MFS) the MFS phase is a good place to split out EH landing pads in both profile and non-profile code. A small change in MFS will enable EH LP splits in profiling given they should always be cold. I think in non-profile mode a sub-flag can be added like -mfs-split-LP-only where EH LPs are always split out. Enabling a general static-analysis splitting could also be interesting but outside of EH LPs I'm not certain there's guaranteed gains in other scenarios.

I'm rebased against 478eb98cd25cb0ebc01fc2c3889ae94d3f1797d3 and I'm seeing both added tests failing. They may need to be updated.

In D86156#2245103, @nikic wrote:

I have no familiarity with BFI, so possibly stupid question: There is already some similar handling as part of BFIImpl here: https://github.com/llvm/llvm-project/blob/0f14b2e6cbb54c84ed3b00b0db521f5ce2d1e3f2/llvm/include/llvm/Analysis/BlockFrequencyInfoImpl.h#L1043-L1058 What is the difference to that / why are both needed?

Remove redundant VH callback as @nikic helpfully pointed out!

Condition usage of BFI to PGO in newPM as well

In D86156#2242872, @asbirlea wrote:

As a general note, it may make sense to include BFI in the set of loop passes always preserved (getLoopPassPreservedAnalyses()), if its nature is to always be preserved (with some potential info loss) due to the callbacks deleting blocks. But since we're only looking at LICM effect for now, this can be a follow up when/if needed.

only use BFI when profile is enabled, have LICM mark BFI as preserved

Remove usage need for BFI in LPM2 and set unswitching to preserve lazy BPI/BFI so it can remain in the same loop pass as LICM

In D86156#2231710, @nikic wrote:

This change adds three PDT calculations to the standard pipeline. Please try to avoid the PDT calculations if PGO is not used, possibly by using LazyBPI.

Change to LazyBFI for legacy pass manager to prevent rebuilding the post-dominator tree

@asbirlea Thanks for taking a look!

Commit my changes (crazy I know) so that the diff is actually updated for linting

Linting