[SLP] Explicit track required stacksave/alloca dependency (try 3)
authorPhilip Reames <listmail@philipreames.com>
Fri, 25 Mar 2022 16:09:02 +0000 (09:09 -0700)
committerPhilip Reames <listmail@philipreames.com>
Fri, 25 Mar 2022 17:04:10 +0000 (10:04 -0700)
commita16308c2823b37721f786a911323f55b313f6d77
tree01b5b6f9183eb05c21f66915903123bdf583edea
parentc7f91e227a799dfee05962bb108274dbfe809fee
[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.
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp