From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25756 invoked by alias); 16 May 2004 10:02:05 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 25748 invoked by uid 48); 16 May 2004 10:02:04 -0000 Date: Mon, 17 May 2004 00:47:00 -0000 From: "kazu at cs dot umass dot edu" To: gcc-bugs@gcc.gnu.org Message-ID: <20040516100200.15473.kazu@cs.umass.edu> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/15473] New: [tree-ssa] Sibcall optimization for libcalls. X-Bugzilla-Reason: CC X-SW-Source: 2004-05/txt/msg01696.txt.bz2 List-Id: Consider: long long foo (long long a, long long b) { return a / b; } I get: foo (a, b) { : return a_1 / b_2; } with the assembly code being foo: subl $12, %esp pushl 28(%esp) pushl 28(%esp) pushl 28(%esp) pushl 28(%esp) call __divdi3 addl $28, %esp ret Note that the sequence of 4 pushl instructions simply copy 16 bytes from one location of the stack to another. If I create a (non-libcall) function with the same arguments like so long long div64 (long long a, long long b); long long bar (long long a, long long b) { return div64 (a, b); } I get: bar (a, b) { long long int T.0; : T.0_3 = div64 (a_1, b_2) [tail call]; return T.0_3; } with the assembly code being bar: jmp div64 -- Summary: [tree-ssa] Sibcall optimization for libcalls. Product: gcc Version: 3.5.0 Status: UNCONFIRMED Keywords: pessimizes-code Severity: enhancement Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at cs dot umass dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15473