[PATCH] D116683: Handle lifetime intrinsics when sinking calls with dead writes

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 5 11:49:31 PST 2022


reames created this revision.
reames added reviewers: nikic, anna.
Herald added subscribers: bollu, hiraditya, mcrosier.
reames requested review of this revision.
Herald added a project: LLVM.

Follow up to D116200 <https://reviews.llvm.org/D116200>, specifically adding the lifetime case.

I'm not terribly happy with this patch, and hoping someone else has a better idea.  The tricky case is when the call is writeonly.  If it read, we could rely on the block scan done for the read case just below, but we end up having to duplicate a bunch of logic just to handle the writeonly case.

A couple of thoughts:

1. Maybe we just shouldn't handle this case?  e.g. allow readwrite calls to be sunk with lifetimes, but bailtout with a comment explaining why?
2. Maybe comesBefore (and potentially numbering the source block) isn't that bad afterall?
3. Maybe we introduce a ScanBlockSuffix flag, reuse the existing code, and accept the false negative of their being unrelated writes in the block suffix?  (Given this only causes additional false negatives for writeonly, maybe that's okay?)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D116683

Files:
  llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
  llvm/test/Transforms/InstCombine/sink_sideeffecting_instruction.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D116683.397651.patch
Type: text/x-patch
Size: 5235 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220105/0201d1fb/attachment.bin>


More information about the llvm-commits mailing list