[all-commits] [llvm/llvm-project] cbf25f: Revert "[CodeGen] [WinException] Only produce hand...

[Hans via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: cbf25fbed5b46ec47e3ce2799ed9095f2f18ea8f
      https://github.com/llvm/llvm-project/commit/cbf25fbed5b46ec47e3ce2799ed9095f2f18ea8f
  Author: Hans Wennborg <hans at chromium.org>
  Date:   2020-11-03 (Tue, 03 Nov 2020)

  Changed paths:
    M llvm/lib/CodeGen/AsmPrinter/WinException.cpp
    M llvm/test/CodeGen/AArch64/win64-jumptable.ll
    M llvm/test/CodeGen/AArch64/wineh1.mir
    M llvm/test/CodeGen/X86/avx512-intel-ocl.ll
    M llvm/test/CodeGen/X86/avx512-regcall-Mask.ll
    M llvm/test/CodeGen/X86/avx512-regcall-NoMask.ll
    M llvm/test/CodeGen/X86/break-false-dep.ll
    M llvm/test/CodeGen/X86/conditional-tailcall-pgso.ll
    M llvm/test/CodeGen/X86/conditional-tailcall.ll
    M llvm/test/CodeGen/X86/gnu-seh-nolpads.ll
    M llvm/test/CodeGen/X86/mingw-comdats.ll
    M llvm/test/CodeGen/X86/mixed-ptr-sizes.ll
    M llvm/test/CodeGen/X86/musttail-varargs.ll
    M llvm/test/CodeGen/X86/no-sse-win64.ll
    M llvm/test/CodeGen/X86/win64-jumptable.ll
    M llvm/test/CodeGen/X86/win64_frame.ll
    M llvm/test/DebugInfo/COFF/defer-complete-type.ll
    M llvm/test/DebugInfo/COFF/enum-co.ll
    M llvm/test/DebugInfo/COFF/global_visibility.ll
    M llvm/test/DebugInfo/COFF/type-quals.ll
    M llvm/test/DebugInfo/COFF/types-basic.ll
    M llvm/test/DebugInfo/COFF/types-data-members.ll
    M llvm/test/DebugInfo/COFF/types-method-ref-qualifiers.ll
    M llvm/test/DebugInfo/COFF/types-recursive-struct.ll

  Log Message:
  -----------
  Revert "[CodeGen] [WinException] Only produce handler data at the end of the function if needed"

This caused an explosion in ICF times during linking on Windows when libfuzzer
instrumentation is enabled. For a small binary we see ICF time go from ~0 to
~10 s. For a large binary it goes from ~1 s to forevert (I gave up after 30
minutes).

See comment on the code review.

> If we are going to write handler data (that is written as variable
> length data following after the unwind info in .xdata), we need to
> emit the handler data immediately, but for cases where no such
> info is going to be written, skip emitting it right away. (Unwind
> info for all remaining functions that hasn't gotten it emitted
> directly is emitted at the end.)
>
> This does slightly change the ordering of sections (triggering a
> bunch of updates to DebugInfo/COFF tests), but the change should be
> benign.
>
> This also matches GCC's assembly output, which doesn't output
> .seh_handlerdata unless it actually is needed.
>
> For ARM64, the unwind info can be packed into the runtime function
> entry itself (leaving no data in the .xdata section at all), but
> that can only be done if there's no follow-on data in the .xdata
> section. If emission of the unwind info is triggered via
> EmitWinEHHandlerData (or the .seh_handlerdata directive), which
> implicitly switches to the .xdata section, there's a chance of the
> caller wanting to pass further data there, so the packed format
> can't be used in that case.
>
> Differential Revision: https://reviews.llvm.org/D87448

This reverts commit 36c64af9d7f97414d48681b74352c9684077259b.