From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31825 invoked by alias); 2 Aug 2010 16:52:49 -0000 Received: (qmail 31813 invoked by uid 22791); 2 Aug 2010 16:52:48 -0000 X-SWARE-Spam-Status: No, hits=-1.8 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; Mon, 02 Aug 2010 16:52:43 +0000 Received: (qmail 25905 invoked from network); 2 Aug 2010 16:52:42 -0000 Received: from unknown (HELO ?192.168.0.105?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Aug 2010 16:52:42 -0000 Message-ID: <4C56F7D6.30600@codesourcery.com> Date: Mon, 02 Aug 2010 16:52:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jie Zhang CC: Richard Guenther , 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> In-Reply-To: <4C563B34.3060706@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00067.txt.bz2 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. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713