[all-commits] [llvm/llvm-project] 787dba: [LICM] Hoisting of widenable conditions out of loops

Philip Reames via All-commits all-commits at lists.llvm.org
Fri Nov 8 08:19:52 PST 2019


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 787dba7aae1d01f3fcf1e471f733f00a6ba66e33
      https://github.com/llvm/llvm-project/commit/787dba7aae1d01f3fcf1e471f733f00a6ba66e33
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2019-11-08 (Fri, 08 Nov 2019)

  Changed paths:
    M llvm/include/llvm/IR/Intrinsics.td
    M llvm/lib/Transforms/Scalar/LICM.cpp
    M llvm/test/Transforms/LICM/explicit_guards.ll

  Log Message:
  -----------
  [LICM] Hoisting of widenable conditions out of loops

The change itself is straight forward and obvious, but ... there's an existing test checking for exactly the opposite. Both I and Artur think this is simply conservatism in the initial implementation.  If anyone bisects a problem to this, a counter example will be very interesting.

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


  Commit: 8d22100f66c4170510c6ff028c60672acfe1cff9
      https://github.com/llvm/llvm-project/commit/8d22100f66c4170510c6ff028c60672acfe1cff9
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2019-11-08 (Fri, 08 Nov 2019)

  Changed paths:
    M llvm/lib/Transforms/Scalar/LICM.cpp
    A llvm/test/Transforms/LICM/hoist-alloca.ll

  Log Message:
  -----------
  [LICM] Support hosting of dynamic allocas out of loops

This patch implements a correct, but not terribly useful, transform. In particular, if we have a dynamic alloca in a loop which is guaranteed to execute, and provably not captured, we hoist the alloca out of the loop. The capture tracking is needed so that we can prove that each previous stack region dies before the next one is allocated. The transform decreases the amount of stack allocation needed by a linear factor (e.g. the iteration count of the loop).

Now, I really hope no one is actually using dynamic allocas. As such, why this patch?

Well, the actual problem I'm hoping to make progress on is allocation hoisting. There's a large draft patch out for review (https://reviews.llvm.org/D60056), and this patch was the smallest chunk of testable functionality I could come up with which takes a step vaguely in that direction.

Once this is in, it makes motivating the changes to capture tracking mentioned in TODOs testable. After that, I hope to extend this to trivial malloc free regions (i.e. free dominating all loop exits) and allocation functions for GCed languages.

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


Compare: https://github.com/llvm/llvm-project/compare/0703db398929...8d22100f66c4


More information about the All-commits mailing list