[LLVMbugs] [Bug 20405] New: tailcallelim incorrectly marks calls as tail if stack is leaked by writing through a function argument
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Tue Jul 22 23:11:47 PDT 2014
http://llvm.org/bugs/show_bug.cgi?id=20405
Bug ID: 20405
Summary: tailcallelim incorrectly marks calls as tail if stack
is leaked by writing through a function argument
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: Scalar Optimizations
Assignee: nlewycky at google.com
Reporter: richard-llvm at metafoo.co.uk
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
tailcallelim marks both calls to @foo in this testcase as 'tail'. It should
not; @hoge leaks a pointer to the stack. (It should still mark @pluto as
'tail', though.)
; ModuleID = 'tmp4.ll'
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-grtev3-linux-gnu"
%struct.barney = type { %struct.hoge }
%struct.hoge = type { i32 (...)**, %struct.hoge.0 }
%struct.hoge.0 = type { %struct.widget }
%struct.widget = type { %struct.eggs }
%struct.eggs = type { %struct.pluto* }
%struct.pluto = type { %struct.wombat* }
%struct.wombat = type opaque
%struct.spam = type { %struct.zot }
%struct.zot = type { %struct.wobble }
%struct.wobble = type { i32*, i64 }
@global = external thread_local(initialexec) global [1000 x i64]
; Function Attrs: nounwind sanitize_memory uwtable
define void @zot(%struct.barney* nocapture readnone %arg) unnamed_addr #0 align
2 {
bb:
%tmp = alloca %struct.spam, align 8
%tmp1 = alloca %struct.spam, align 8
%tmp2 = alloca [1 x i32], align 4
%tmp3 = alloca %struct.spam, align 8
%tmp4 = alloca [4 x i32], align 4
call void @baz(%struct.spam* %tmp)
%tmp5 = getelementptr inbounds %struct.spam* %tmp, i64 0, i32 0, i32 0, i32 0
%tmp6 = load i32** %tmp5, align 8
%tmp7 = getelementptr %struct.spam* %tmp, i64 0, i32 0, i32 0, i32 1
%tmp8 = load i64* %tmp7, align 8
call fastcc void @pluto(i32* %tmp6, i64 %tmp8)
%tmp9 = getelementptr inbounds [1 x i32]* %tmp2, i64 0, i64 0
store i32 1, i32* %tmp9, align 4
call void @hoge(%struct.spam* %tmp1, i32* %tmp9, i64 1)
%tmp10 = getelementptr inbounds %struct.spam* %tmp1, i64 0, i32 0, i32 0, i32
0
%tmp11 = load i32** %tmp10, align 8
%tmp12 = getelementptr %struct.spam* %tmp1, i64 0, i32 0, i32 0, i32 1
%tmp13 = load i64* %tmp12, align 8
call fastcc void @foo(i32* %tmp11, i64 %tmp13, i32 1, i32 1)
%tmp14 = getelementptr inbounds [4 x i32]* %tmp4, i64 0, i64 0
store i32 10, i32* %tmp14, align 4
%tmp15 = getelementptr inbounds [4 x i32]* %tmp4, i64 0, i64 1
store i32 11, i32* %tmp15, align 4
%tmp16 = getelementptr inbounds [4 x i32]* %tmp4, i64 0, i64 2
store i32 12, i32* %tmp16, align 4
%tmp17 = getelementptr inbounds [4 x i32]* %tmp4, i64 0, i64 3
store i32 13, i32* %tmp17, align 4
call void @hoge(%struct.spam* %tmp3, i32* %tmp14, i64 4)
%tmp18 = getelementptr inbounds %struct.spam* %tmp3, i64 0, i32 0, i32 0, i32
0
%tmp19 = load i32** %tmp18, align 8
%tmp20 = getelementptr %struct.spam* %tmp3, i64 0, i32 0, i32 0, i32 1
%tmp21 = load i64* %tmp20, align 8
call fastcc void @foo(i32* %tmp19, i64 %tmp21, i32 10, i32 13)
ret void
}
; Function Attrs: nounwind sanitize_memory uwtable
declare hidden void @pluto(i32*, i64) #0
; Function Attrs: nounwind sanitize_memory uwtable
declare void @baz(%struct.spam* nocapture) unnamed_addr #0 align 2
; Function Attrs: nounwind sanitize_memory uwtable
declare hidden void @foo(i32*, i64, i32, i32) #0
; Function Attrs: nounwind sanitize_memory uwtable
declare void @hoge(%struct.spam* nocapture, i32*, i64) unnamed_addr #0 align 2
; Function Attrs: nounwind
declare void @llvm.memset.p0i8.i64(i8* nocapture, i8, i64, i32, i1) #1
attributes #0 = { nounwind sanitize_memory uwtable "less-precise-fpmad"="false"
"no-frame-pointer-elim"="false" "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false" "no-nans-fp-math"="false"
"stack-protector-buffer-size"="8" "unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #1 = { nounwind }
--
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/20140723/8ad3347e/attachment.html>
More information about the llvm-bugs
mailing list