File: 2010-05-31-ByvalTailcall.ll

package info (click to toggle)
llvm-3.0 3.0-10
  • links: PTS, VCS
  • area: main
  • in suites: wheezy
  • size: 75,412 kB
  • sloc: cpp: 468,043; asm: 109,345; ansic: 13,782; sh: 12,935; ml: 4,716; python: 4,351; perl: 2,096; makefile: 1,905; pascal: 1,578; exp: 389; xml: 283; lisp: 187; csh: 117
file content (24 lines) | stat: -rw-r--r-- 819 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
; RUN: opt < %s -tailcallelim -inline -instcombine -dse -S | FileCheck %s
; PR7272

; When inlining through a byval call site, the inliner creates allocas which may
; be used by inlined calls, so any inlined calls need to have their 'tail' flags
; cleared.  If not then you can get nastiness like with this testcase, where the
; (inlined) call to 'ext' in 'foo' was being passed an uninitialized value.

target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
target triple = "i386-pc-linux-gnu"

declare void @ext(i32*)

define void @bar(i32* byval %x) {
  call void @ext(i32* %x)
  ret void
}

define void @foo(i32* %x) {
; CHECK: define void @foo
; CHECK: store i32 %1, i32* %x
  call void @bar(i32* byval %x)
  ret void
}