[all-commits] [llvm/llvm-project] 7b54de: [funcattrs] Fix a bug in recently introduced write...

Philip Reames via All-commits all-commits at lists.llvm.org
Fri Dec 3 09:10:00 PST 2021

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7b54de5feffedfc08e5a02d6c9e27c54e3b7f119
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2021-12-03 (Fri, 03 Dec 2021)

  Changed paths:
    M clang/test/CodeGen/ms-mixed-ptr-sizes.c
    M llvm/lib/Transforms/IPO/FunctionAttrs.cpp
    M llvm/test/Feature/OperandBundles/pr26510.ll
    M llvm/test/Transforms/Coroutines/coro-async.ll
    M llvm/test/Transforms/FunctionAttrs/2009-01-02-LocalStores.ll
    M llvm/test/Transforms/FunctionAttrs/nocapture.ll
    M llvm/test/Transforms/FunctionAttrs/readattrs.ll
    M llvm/test/Transforms/FunctionAttrs/writeonly.ll

  Log Message:
  [funcattrs] Fix a bug in recently introduced writeonly argument inference

This fixes a bug in 740057d.  There's two ways to describe the issue:
* One caller hasn't yet proven nocapture on the argument.  Given that, the inference routine is responsible for bailing out on a potential capture.
* Even if we know the argument is nocapture, the access inference needs to traverse the exact set of users the capture tracking would (or exit conservatively).  Even if capture tracking can prove a store is non-capturing (e.g. to a local alloc which doesn't escape), we still need to track the copy of the pointer to see if it's later reloaded and accessed again.

Note that all the test changes except the newly added ones appear to be false negatives.  That is, cases where we could prove writeonly, but the current code isn't strong enough.  That's why I didn't spot this originally.

More information about the All-commits mailing list