[LLVMbugs] [Bug 3361] New: Should be possible to share stack slots when variables have non-overlapping liveness

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Tue Jan 20 09:04:50 PST 2009


http://llvm.org/bugs/show_bug.cgi?id=3361

           Summary: Should be possible to share stack slots when variables
                    have non-overlapping liveness
           Product: new-bugs
           Version: unspecified
          Platform: PC
               URL: http://lkml.org/lkml/2009/1/12/344
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


See the URL for a detailed description of the problem, criticising gcc.

In short: stack usage should be "b + c", but it is "a + b (+ c)"
a is no longer live when b and c are used, thus they could share stack slots.
(they would have gotten different addresses, if they weren't inlined).

I tested with LLVM-gcc, and it seems that 'gcc -fno-strict-aliasing' performs
better in reducing stack size (however it is slightly better than gcc with
default strict-aliasing)

$ llvm-gcc -O2 -S -m32  linus.c; grep subl linus.s
        subl    $1632, %esp

$ gcc-4.3 -O2 linus.c; grep subl linus.s
        subl    $1640, %esp

$ gcc-4.3 -O2 -S -fno-strict-aliasing -m32  linus.c
        subl    $1240, %esp

Are there any flags to get the same (or better) stack usage as gcc's with
-fno-strict-aliasing? 

Here is the testcase as bitcode:
; ModuleID = 'linus.c'
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"
target triple = "i386-unknown-linux-gnu"
        %struct.a = type { i32, [200 x i32] }
        %struct.b = type { i32, [100 x i32] }

define i32 @fn(i32 %flag) nounwind {
entry:
        %c.i = alloca %struct.b         ; <%struct.b*> [#uses=1]
        %b.i = alloca %struct.b         ; <%struct.b*> [#uses=1]
        %a.i = alloca %struct.a         ; <%struct.a*> [#uses=1]
        %a1.i = bitcast %struct.a* %a.i to i8*          ; <i8*> [#uses=1]
        %0 = call i32 @fn3(i32 %flag, i8* %a1.i) nounwind               ; <i32>
[#uses=0]
        %1 = and i32 %flag, 1           ; <i32> [#uses=1]
        %toBool = icmp eq i32 %1, 0             ; <i1> [#uses=1]
        br i1 %toBool, label %bb1, label %bb2

bb1:            ; preds = %entry
        %b1.i = bitcast %struct.b* %b.i to i8*          ; <i8*> [#uses=1]
        %2 = call i32 @fn4(i32 %flag, i8* %b1.i) nounwind               ; <i32>
[#uses=1]
        %c2.i = bitcast %struct.b* %c.i to i8*          ; <i8*> [#uses=1]
        %3 = call i32 @fn4(i32 %flag, i8* %c2.i) nounwind               ; <i32>
[#uses=1]
        %4 = add i32 %3, %2             ; <i32> [#uses=1]
        ret i32 %4

bb2:            ; preds = %entry
        ret i32 0
}

declare i32 @fn3(i32, i8*)

declare i32 @fn4(i32, i8*)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list