[all-commits] [llvm/llvm-project] 42465e: [BOLT] Increase coverage of shrink wrapping [1/5]

[Rafael Auler via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 42465efd171727fff0686537def45f32efb67088
      https://github.com/llvm/llvm-project/commit/42465efd171727fff0686537def45f32efb67088
  Author: Rafael Auler <rafaelauler at fb.com>
  Date:   2022-07-11 (Mon, 11 Jul 2022)

  Changed paths:
    M bolt/include/bolt/Passes/AllocCombiner.h
    M bolt/include/bolt/Passes/DataflowAnalysis.h
    M bolt/include/bolt/Passes/FrameAnalysis.h
    M bolt/include/bolt/Passes/FrameOptimizer.h
    M bolt/include/bolt/Passes/ShrinkWrapping.h
    M bolt/lib/Core/BinaryFunction.cpp
    M bolt/lib/Passes/AllocCombiner.cpp
    M bolt/lib/Passes/FrameAnalysis.cpp
    M bolt/lib/Passes/FrameOptimizer.cpp
    M bolt/lib/Passes/ShrinkWrapping.cpp
    M bolt/test/X86/shrinkwrapping-pop-order.s

  Log Message:
  -----------
  [BOLT] Increase coverage of shrink wrapping [1/5]

Change how function score is calculated and provide more
detailed statistics when reporting back frame optimizer and shrink
wrapping results. In this new statistics, we provide dynamic coverage
numbers. The main metric for shrink wrapping is the number of executed
stores that were saved because of shrink wrapping (push instructions
that were either entirely moved away from the hot block or converted
to a stack adjustment instruction). There is still a number of reduced
load instructions (pop) that we are not counting at the moment. Also
update alloc combiner to report dynamic numbers, as well as frame
optimizer.

For debugging purposes, we also include a list of top 10 functions
optimized by shrink wrapping. These changes are aimed at better
understanding the impact of shrink wrapping in a given binary.

We also remove an assertion in dataflow analysis to do not choke on
empty functions (which makes no sense).

Reviewed By: Amir

Differential Revision: https://reviews.llvm.org/D126111


  Commit: 3508ced6ea239d17b2f4a79a91b8398d0d1ac514
      https://github.com/llvm/llvm-project/commit/3508ced6ea239d17b2f4a79a91b8398d0d1ac514
  Author: Rafael Auler <rafaelauler at fb.com>
  Date:   2022-07-11 (Mon, 11 Jul 2022)

  Changed paths:
    M bolt/lib/Target/X86/X86MCPlusBuilder.cpp

  Log Message:
  -----------
  [BOLT] Increase coverage of shrink wrapping [2/5]

Refactor isStackAccess() to reflect updates by D126116. Now we only
handle simple stack accesses and delegate the rest of the cases to
getMemDataSize.

Reviewed By: Amir

Differential Revision: https://reviews.llvm.org/D126112


  Commit: 3332904ad6fad848a77c46d0432e8b55a10c1079
      https://github.com/llvm/llvm-project/commit/3332904ad6fad848a77c46d0432e8b55a10c1079
  Author: Rafael Auler <rafaelauler at fb.com>
  Date:   2022-07-11 (Mon, 11 Jul 2022)

  Changed paths:
    M bolt/include/bolt/Passes/MCF.h
    M bolt/include/bolt/Utils/CommandLineOpts.h
    M bolt/lib/Passes/FrameOptimizer.cpp
    M bolt/lib/Passes/MCF.cpp
    M bolt/lib/Passes/ShrinkWrapping.cpp
    M bolt/lib/Utils/CommandLineOpts.cpp
    A bolt/test/X86/shrinkwrapping-do-not-pessimize.s

  Log Message:
  -----------
  [BOLT] Increase coverage of shrink wrapping [3/5]

Add the option to run -equalize-bb-counts before shrink
wrapping to avoid unnecessarily optimizing some CFGs where profile is
inaccurate but we can prove two blocks have the same frequency.

Reviewed By: Amir

Differential Revision: https://reviews.llvm.org/D126113


  Commit: 3e5f67f356a1b9dc31df72ac846e688143ce8a48
      https://github.com/llvm/llvm-project/commit/3e5f67f356a1b9dc31df72ac846e688143ce8a48
  Author: Rafael Auler <rafaelauler at fb.com>
  Date:   2022-07-11 (Mon, 11 Jul 2022)

  Changed paths:
    M bolt/include/bolt/Passes/ShrinkWrapping.h
    M bolt/lib/Passes/ShrinkWrapping.cpp

  Log Message:
  -----------
  [BOLT] Increase coverage of shrink wrapping [4/5]

Change shrink-wrapping to try a priority list of save
positions, instead of trying the best one and giving up if it doesn't
work. This also increases coverage.

Reviewed By: Amir

Differential Revision: https://reviews.llvm.org/D126114


  Commit: a3cfdd746e96a2e45953e5db1a6c87b925d16c8d
      https://github.com/llvm/llvm-project/commit/a3cfdd746e96a2e45953e5db1a6c87b925d16c8d
  Author: Rafael Auler <rafaelauler at fb.com>
  Date:   2022-07-11 (Mon, 11 Jul 2022)

  Changed paths:
    M bolt/include/bolt/Passes/FrameAnalysis.h
    M bolt/lib/Passes/FrameAnalysis.cpp
    M bolt/lib/Passes/FrameOptimizer.cpp
    M bolt/lib/Passes/ShrinkWrapping.cpp
    M bolt/lib/Target/X86/X86MCPlusBuilder.cpp
    A bolt/test/X86/frame-opt-lea.s
    A bolt/test/X86/shrinkwrapping-lea.s
    A bolt/test/X86/shrinkwrapping-mov.s
    M bolt/test/X86/shrinkwrapping-popf.s
    A bolt/test/X86/shrinkwrapping-restore-position.s

  Log Message:
  -----------
  [BOLT] Increase coverage of shrink wrapping [5/5]

Add -experimental-shrink-wrapping flag to control when we
want to move callee-saved registers even when addresses of the stack
frame are captured and used in pointer arithmetic, making it more
challenging to do alias analysis to prove that we do not access
optimized stack positions. This alias analysis is not yet implemented,
hence, it is experimental. In practice, though, no compiler would emit
code to do pointer arithmetic to access a saved callee-saved register
unless there is a memory bug or we are failing to identify a
callee-saved reg, so I'm not sure how useful it would be to formally
prove that.

Reviewed By: Amir

Differential Revision: https://reviews.llvm.org/D126115


Compare: https://github.com/llvm/llvm-project/compare/77ccc480baf6...a3cfdd746e96