[llvm-bugs] [Bug 29057] New: GVN PRE not respecting the "inbounds" keyword of GEP

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: youngju.song at sf.snu.ac.kr
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160819/da3b8213/attachment.html>