From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27536 invoked by alias); 26 Feb 2011 03:37:08 -0000 Received: (qmail 27440 invoked by uid 22791); 26 Feb 2011 03:37:07 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wy0-f169.google.com (HELO mail-wy0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Feb 2011 03:37:00 +0000 Received: by wyi11 with SMTP id 11so2645325wyi.0 for ; Fri, 25 Feb 2011 19:36:57 -0800 (PST) Received: by 10.216.168.82 with SMTP id j60mr105692wel.47.1298691417726; Fri, 25 Feb 2011 19:36:57 -0800 (PST) Received: from [192.168.2.99] (cpc2-cmbg8-0-0-cust61.5-4.cable.virginmedia.com [82.6.108.62]) by mx.google.com with ESMTPS id f27sm1130393wbf.13.2011.02.25.19.36.55 (version=SSLv3 cipher=OTHER); Fri, 25 Feb 2011 19:36:56 -0800 (PST) Message-ID: <4D687545.8010303@gmail.com> Date: Sat, 26 Feb 2011 03:37:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "H.J. Lu" CC: "binutils@sourceware.org" Subject: Re: [PATCH,trunk+2.20] Fix issues in ld.bfd plugin interface [0/6] References: <4D684CB8.6020106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00341.txt.bz2 On 26/02/2011 02:14, H.J. Lu wrote: > > The question is if LTO linker should link in non-LTO copy of the same function > and ignore the LTO-IR copy: Well, I think the linker should link at least one of them in, preferably the IR one if it can so that it can be optimised along with the rest of the program, but if for some reason the linker can't see that it's needed until after ltrans, then it has no choice but to link the non-LTO copy, and settle for what should after all only be a missed optimisation rather than correctness problem. > [hjl@gnu-6 pr12496-2]$ make > as --32 -o start.o start.s > /usr/gcc-4.6/bin/gcc -m32 -B./ -flto -c -o main.o main.c > /usr/gcc-4.6/bin/gcc -m32 -B./ -flto -c -o div.o div.c > ar rv libdiv.a div.o > ar: creating libdiv.a > a - div.o > /usr/gcc-4.6/bin/gcc -m32 -B./ -O2 -flto -nostdlib -o prog > -Wl,--start-group start.o main.o libdiv.a -Wl,--end-group When I tried this with ld.hjl on i686-pc-cygwin, I got an undefined reference to __udivdi3, is that supposed to happen? > Here div.o is compiled with -O0 -flto and the final link is compiled > with -O2 -flto. I would expect div.c is compiled with -O2 -flto, not -O0, > if div.c is linked in. Am I expecting too much? Well, to make that work, wouldn't we have to treat all archives as if they were opened in --whole-archive mode during stage1, and let the plugin claim every archive member that contains any IR and then rely on LTRANS to optimise away all but the used code, right? I must admit I don't understand why LTO doesn't emit undefs in the LTO symtab for builtins. I think life would be easier all round if the LTO symtab for main.o contained a reference to __udivdi3 all along, so that we could just let the usual mechanism pull in all (and only) the needed stuff straight off in stage1 and not give LTRANS so much redundant work to do. cheers, DaveK