[PATCH] D37460: [GVN] Prevent LoadPRE from hoisting across instructions that don't pass control flow to successors

[Michael Ferguson via Phabricator via llvm-commits]

mppf added a comment.

Hi @mkazantsev , this change seems to have caused a regression. Before this change, the following program compiled with `opt -gvn minimal64.ll -S` but after, it causes an assertion failure in the compiler. I've verified that this failure is still present on trunk as of r315579.

  GVN.cpp:1073: bool llvm::GVN::PerformLoadPRE(llvm::LoadInst*, llvm::GVN::AvailValInBlkVect&, llvm::GVN::UnavailBlkVect&): Assertion `It->second->getParent() == TmpBB && "Implicit control flow map broken?"' failed.

Here is a carefully minimized test case (from a failure compiling with our frontend):

  ; ModuleID = 'simpler.ll'
  source_filename = "bugpoint-output-5fd3360.bc"
  target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
  target triple = "x86_64-unknown-linux-gnu"
  
  %ArrayImpl = type { i64, i64 addrspace(100)*, [1 x i64], [1 x i64], [1 x i64], i64, i64, double addrspace(100)*, double addrspace(100)*, i8, i64 }
  
  ; Function Attrs: readnone
  declare %ArrayImpl* @getaddr_ArrayImpl(%ArrayImpl addrspace(100)*) #0
  
  ; Function Attrs: readnone
  declare i64* @getaddr_i64(i64 addrspace(100)*) #0
  
  define hidden void @wrapon_fn173() {
  entry:
    %0 = call %ArrayImpl* @getaddr_ArrayImpl(%ArrayImpl addrspace(100)* undef)
    br label %loop
  
  loop:
    %1 = call %ArrayImpl* @getaddr_ArrayImpl(%ArrayImpl addrspace(100)* undef)
    %2 = load i64 addrspace(100)*, i64 addrspace(100)** null, align 8
    %3 = call i64* @getaddr_i64(i64 addrspace(100)* %2)
    br label %loop
  }
  
  attributes #0 = { readnone }

To reproduce, put the above into minimal64.ll and run `opt -gvn minimal64.ll -S`.

Note that if the "readnone" attribute is removed from the getaddr functions, the test will pass.

I'd greatly appreciate any attention you can give to this matter. (I'd make a bug report but don't have an account on the bug report server yet).

Thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D37460