https://llvm.org/bugs/show_bug.cgi?id=29057

            Bug ID: 29057
           Summary: GVN PRE not respecting the "inbounds" keyword of GEP
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedb...@nondot.org
          Reporter: youngju.s...@sf.snu.ac.kr
                CC: llvm-bugs@lists.llvm.org
    Classification: Unclassified

Related with: https://llvm.org/bugs/show_bug.cgi?id=28562

As stated, GVN ignores the "inbounds" keyword of GEP during numbering.

And it actually performs PRE on GEP regardless of "inbounds" keyword.

Below is the actual code transformation. (Using 'opt -gvn')


source:

================================================================
define i32* @foo(i32* %a, i1 %cond) {
entry:
  br i1 %cond, label %brA, label %brB

brA:
  %xA = getelementptr inbounds i32, i32* %a, i32 10
  br label %out

brB:
  %xB = getelementptr inbounds i32, i32* %a, i32 10
  br label %out

out:
  %x = getelementptr i32, i32* %a, i32 10
  ret i32* %x
}
================================================================





target:

================================================================
define i32* @foo(i32* %a, i1 %cond) {
entry:
  br i1 %cond, label %brA, label %brB

brA:                                              ; preds = %entry
  %xA = getelementptr inbounds i32, i32* %a, i32 10
  br label %out

brB:                                              ; preds = %entry
  %xB = getelementptr inbounds i32, i32* %a, i32 10
  br label %out

out:                                              ; preds = %brB, %brA
  %x.pre-phi = phi i32* [ %xB, %brB ], [ %xA, %brA ]
  ret i32* %x.pre-phi
}
================================================================

This may be problematic because GEP with "inbounds" keyword may produce poison
value while normal one does not, and poison value may produce UB. More behavior
in target code is problematic.
One possible solution may to use "patchAndReplaceAllUsesWith" instead of naive
"replaceAllUsesWith" in "performScalarPRE".

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to