From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29589 invoked by alias); 3 Aug 2010 09:59:02 -0000 Received: (qmail 29579 invoked by uid 22791); 3 Aug 2010 09:59:01 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Aug 2010 09:58:57 +0000 Received: (qmail 7088 invoked from network); 3 Aug 2010 09:58:53 -0000 Received: from unknown (HELO ?192.168.1.100?) (jie@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Aug 2010 09:58:53 -0000 Message-ID: <4C57E85A.2030304@codesourcery.com> Date: Tue, 03 Aug 2010 09:59:00 -0000 From: Jie Zhang User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Richard Guenther CC: Mark Mitchell , GCC Patches Subject: Re: [RFC] Don't completely scalarize a record if it contains bit-field (PR tree-optimization/45144) References: <4C52F946.6010404@codesourcery.com> <4C5307CE.3020708@codesourcery.com> <4C563B34.3060706@codesourcery.com> <4C56F7D6.30600@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00175.txt.bz2 On 08/03/2010 05:00 PM, Richard Guenther wrote: > On Mon, Aug 2, 2010 at 6:52 PM, Mark Mitchell wrote: >> Jie Zhang wrote: >> >>> My patch prevents several full scalarizations of records with bit-field >>> when compiling Linux kernel for x86_64, but none of these causes >>> differences in final assemblies. I use 2.6.34.1 and the default config >>> for x86_64. I checked -O2 and -Os. >> >> That seems at odds with the statement made previously in this thread >> that this optimization was essential for Linux kernel performance. >> >> If Jie's statement is accurate, then, whether or not this is a "hack", >> it seems like a win. I don't see anything wrong with accepting a small, >> local improvement that has no user-observable negative impact; we can >> always rip it out and replace it with something better when something >> better exists. > > OTOH no changes in code generation are also not in favor of this > patch. Why didn't it improve anything? Or was that expected? > Only two total scalarizations are prevented by my patch when building the linux kernel for the default x86_64 config, which compiles 1646 C files. One is in io_apic.c:ioapic_write_entry (), "struct IO_APIC_route_entry e". The other is in fs-writeback.c:bdi_sync_writeback (), "struct wb_writeback_args args". In both cases, those structs are used simply as a whole. GCC can already optimize away the parts generated by total scalarization. So there is no difference when it's disabled. > Can you adjust the patch according to Martins suggestion? > OK. Thanks, -- Jie Zhang CodeSourcery