[llvm-bugs] [Bug 27977] New: optimizer struggles with -fsanitize=bounds in simple loop

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Jun 2 02:13:51 PDT 2016


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

            Bug ID: 27977
           Summary: optimizer struggles with -fsanitize=bounds in simple
                    loop
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: eli.friedman at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

C testcase:

-----------

 char template_buffer[257];
 void
 init_template_buffer (void)
 {
   int i;

   i = 0;
   while (i < 256)
     {
       template_buffer[i] = (char) i;
       i++;
     }
   template_buffer[256] = (char) 0;
   return;
 }

-----------

Compile with clang -emit-llvm -O2 -fsanitize=bounds:

-----------

; ModuleID = '-'
source_filename = "-"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@template_buffer = global [257 x i8] zeroinitializer, align 16

; Function Attrs: nounwind uwtable
define void @_Z20init_template_bufferv() #0 {
entry:
  br label %cont

cont:                                             ; preds = %2, %entry
  %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next.1, %2 ]
  %i.07 = phi i32 [ 0, %entry ], [ %inc.1, %2 ]
  %sext = shl i64 %indvars.iv, 32
  %0 = ashr exact i64 %sext, 32
  %1 = icmp ugt i64 %0, 271
  br i1 %1, label %trap, label %cont.18

cont.18:                                          ; preds = %cont
  %arrayidx = getelementptr inbounds [257 x i8], [257 x i8]* @template_buffer,
i64 0, i64 %0
  %conv = trunc i32 %i.07 to i8
  store i8 %conv, i8* %arrayidx, align 2, !tbaa !1
  br i1 false, label %trap, label %2

cont2:                                            ; preds = %2
  store i8 0, i8* getelementptr inbounds ([257 x i8], [257 x i8]*
@template_buffer, i64 0, i64 256), align 16, !tbaa !1
  ret void

trap:                                             ; preds = %cont.18, %cont
  call void @llvm.trap() #1
  unreachable

; <label>:2:                                      ; preds = %cont.18
  %inc = or i32 %i.07, 1
  %indvars.iv.next = shl i64 %indvars.iv, 32
  %sext.1 = ashr exact i64 %indvars.iv.next, 32
  %3 = or i64 %sext.1, 1
  %arrayidx.1 = getelementptr inbounds [257 x i8], [257 x i8]*
@template_buffer, i64 0, i64 %3
  %conv.1 = trunc i32 %inc to i8
  store i8 %conv.1, i8* %arrayidx.1, align 1, !tbaa !1
  %indvars.iv.next.1 = add nsw i64 %indvars.iv, 2
  %inc.1 = add nsw i32 %i.07, 2
  %exitcond.1 = icmp eq i64 %indvars.iv.next.1, 256
  br i1 %exitcond.1, label %cont2, label %cont
}

; Function Attrs: noreturn nounwind
declare void @llvm.trap() #1

attributes #0 = { nounwind uwtable "disable-tail-calls"="false"
"less-precise-fpmad"="false" "no-frame-pointer-elim"="false"
"no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false"
"stack-protector-buffer-size"="8" "target-cpu"="x86-64"
"target-features"="+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #1 = { noreturn nounwind }

!llvm.ident = !{!0}

!0 = !{!"clang version 3.9.0 (http://llvm.org/git/clang
0b910bfbcda6b6c64afee2462018139ac9cef715) (http://llvm.org/git/llvm.git
dfc9470f337f6a7b9a797bae104d8d5c2ac5e48e)"}
!1 = !{!2, !2, i64 0}
!2 = !{!"omnipotent char", !3, i64 0}
!3 = !{!"Simple C++ TBAA"}

-----------

Scalar evolution analysis of %0 from above IR:
  %0 = ashr exact i64 %sext, 32
  -->  (sext i32 {0,+,2}<nuw><nsw><%cont> to i64) U: [-2147483648,2147483648)
S: [-2147483648,2147483647)        Exits: <<Unknown>>        LoopDispositions:
{ %cont: Computable }

-----------

Not completely sure what's happening, but it looks like the optimizer is
confusing itself, and maybe the bounds check insertion pass is running later
than it should.

-- 
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/20160602/56ca469a/attachment.html>


More information about the llvm-bugs mailing list