[LLVMdev] Missed optimization on array initialization

Carlo Alberto Ferraris cafxx at strayorange.com
Sat Feb 25 03:17:29 PST 2012

Prompted by a SO post 
I checked and found that LLVM yields the same (seemingly) suboptimal 
code as MSVC.
Consider the following, simplified, C snippet:

extern void bar(int*);

void foo(int a)
     int ar[100] = {a};
     if (a)

Ideally, the array initialization should be sank after the return, but 
in Clang/LLVM 3.0 this doesn't happen:

; ModuleID = '/tmp/webcompile/_11079_0.bc'
target  datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target  triple = "x86_64-unknown-linux-gnu"

define  void  @_Z3fooi(i32  %a) uwtable {
   %ar =alloca  [100 xi32],align  16
   %1 =bitcast  [100 xi32]* %arto  i8*
   call  void  @llvm.memset.p0i8.i64(i8* %1,i8  0,i64  400,i32  16,i1  false)
   %2 =getelementptr  inbounds [100 xi32]* %ar,i64  0,i64  0
   store  i32  %a,i32* %2,align  16, !tbaa !0
   %3 =icmp  eq  i32  %a, 0
   br  i1  %3,label  %4,label  %5

;<label>:4                                       ; preds = %0
   call  void  @_Z3barPi(i32* %2)
   br  label  %5

;<label>:5                                       ; preds = %4, %0
   ret  void

declare  void  @llvm.memset.p0i8.i64(i8*nocapture,i8,i64,i32,i1)nounwind

declare  void  @_Z3barPi(i32*)

!0 = metadata !{metadata !"int", metadata !1}
!1 = metadata !{metadata !"omnipotent char", metadata !2}
!2 = metadata !{metadata !"Simple C/C++ TBAA",null}

and this gets emitted as (for x64, but x86 is similar):

# BB#0:
	pushq	%rbx
	.cfi_def_cfa_offset 16
	subq	$400, %rsp              # imm = 0x190
	.cfi_def_cfa_offset 416
	.cfi_offset %rbx, -16
	movl	%edi, %ebx
	leaq	(%rsp), %rdi
	xorl	%esi, %esi
	movl	$400, %edx              # imm = 0x190
	callq	memset
	movl	%ebx, (%rsp)
	testl	%ebx, %ebx
	jne	.LBB0_2
# BB#1:
	leaq	(%rsp), %rdi
	callq	_Z3barPi
	addq	$400, %rsp              # imm = 0x190
	popq	%rbx

I don't have ToT at hand, so I don't know if this is still the case. Any 
idea why this might be happening?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120225/4969db25/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cafxx.vcf
Type: text/x-vcard
Size: 230 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120225/4969db25/attachment.vcf>

More information about the llvm-dev mailing list