[all-commits] [llvm/llvm-project] a16308: [SLP] Explicit track required stacksave/alloca dep...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a16308c2823b37721f786a911323f55b313f6d77
      https://github.com/llvm/llvm-project/commit/a16308c2823b37721f786a911323f55b313f6d77
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2022-03-25 (Fri, 25 Mar 2022)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp

  Log Message:
  -----------
  [SLP] Explicit track required stacksave/alloca dependency (try 3)

This is an extension of commit b7806c to handle one last case noticed in test changes for D118538.  Again, this is thought to be a latent bug in the existing code, though this time I have not managed to reduce tests for the original algoritthm.

The prior attempt had failed to account for this case:
  %a = alloca i8
  stacksave
  stackrestore
  store i8 0, i8* %a

If we allow '%a' to reorder into the stacksave/restore region, then the alloca will be deallocated before the use.  We will have taken a well defined program, and introduced a use-after-free bug.

There's also an inverse case where the alloca originally follows the stackrestore, and we need to prevent the reordering it above the restore.

Compile time wise, we potentially do an extra scan of the block for each alloca seen in a bundle.  This is significantly more expensive than the stacksave rooted version and is why I'd tried to avoid this in the initial patch.  There is room to optimize this (by essentially caching a "has stacksave" bit per block), but I'm leaving that to future work if it actually shows up in practice.  Since allocas in bundles should be rare in practice, I suspect we can defer the complexity for a long while.


  Commit: ec858f02015c32c683852fe72761a2e610dc5785
      https://github.com/llvm/llvm-project/commit/ec858f02015c32c683852fe72761a2e610dc5785
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2022-03-25 (Fri, 25 Mar 2022)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp

  Log Message:
  -----------
  [SLP] Optimize stacksave dependence handling [NFC]

After writing the commit message for 4b1bace28, realized that the mentioned optimization was rather straight forward.  We already have the code for scanning a block during region initialization, we can simply keep track if we've seen a stacksave or stackrestore.  If we haven't, none of these dependencies are relevant and we can avoid the relatively expensive scans entirely.


Compare: https://github.com/llvm/llvm-project/compare/c7f91e227a79...ec858f02015c