[PATCH] D131776: [GVN] Fix miscompile shown in github issue #57025

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 1 06:07:49 PDT 2022


nikic added inline comments.


================
Comment at: llvm/lib/Transforms/Scalar/GVN.cpp:1297
+      // available.
+      if (DepInfo.isUnknown()) {
+        UnavailableBlocks.push_back(DepBB);
----------------
bjope wrote:
> I've tried replacing this with `assert(!DepInfo.isUnknown())` and it seems like that is a totally untested scenario (except for the new test/Transforms/GVN/memdep-unknown-deadblocks.ll test case).
> 
> So even if D131776 is a better fix in some sense, I'm still wondering what would be correct to do if getting here with a DepInfo that is `Unknown`. At least when I looked at this a couple of weeks ago I got the feeling that the behavior without this patch could be wrong and that adding to UnavailableBlocks would be more correct as we do not know if there is a dependent mem-op or not. Or am I missing something.
> 
> Given that D131776 probably will hide this code path also for the memdep-unknown-deadblocks.ll test case, then I'm not sure how to motivate this fix. If we never expect to get here with DepInfo.isUnknown, then maybe we should assert on that instead.
> 
> I'll try to run some fuzzy testing to see if I can trigger this code path even with the fix from D131776.
I don't think this code path cares about the value of DepInfo at all. If the block is unreachable, then we can always assume it produces a poison value.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131776/new/

https://reviews.llvm.org/D131776



More information about the llvm-commits mailing list