From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2556 invoked by alias); 2 Aug 2010 03:28:01 -0000 Received: (qmail 2539 invoked by uid 22791); 2 Aug 2010 03:28:00 -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; Mon, 02 Aug 2010 03:27:55 +0000 Received: (qmail 13311 invoked from network); 2 Aug 2010 03:27:53 -0000 Received: from unknown (HELO ?192.168.1.100?) (jie@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Aug 2010 03:27:53 -0000 Message-ID: <4C563B34.3060706@codesourcery.com> Date: Mon, 02 Aug 2010 03:28: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: Mark Mitchell 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> In-Reply-To: <4C5307CE.3020708@codesourcery.com> 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/msg00026.txt.bz2 On 07/31/2010 01:11 AM, Mark Mitchell wrote: > Richard Guenther wrote: > >>> Until the aggregates copy propagation is implemented, I think it would >>> better to disable full scalarization for such records. The patch is >>> attached. It's bootstrapped on x86_64-linux-gnu and regression tested. > >> Without looking at the patch I have two comments. > > From reading your comments, I'm not sure if you're saying that you don't > like Jie's idea, or if you think it's an OK idea, but there are some > other things that you would like to see done as well or instead. It > would be helpful if you could make that clear. > > To me, Jie's change seems like a plausible heuristic within the current > infrastructure. I'm all for building new infrastructure when > possible/necessary, but I don't think we should prevent these kinds of > tweaks to heuristics just because we can think of another way of doing > things. To me, the question ought to be "does this make the compiler > better for users?" > > To answer that question, what I guess I'd like to know is what the > impact is on some benchmark that matters. Here, I don't think SPEC, > EEMBC, etc. are probably the right places to look; they probably don't > have much of this kind of code. Perhaps it would be interesting to know > how many SRA opportunities we lose in the Linux kernel because of this > change -- and then spot-check some of them to see whether those are > cases where we really lose by not doing SRA, or really win because we're > not doing the kind of ugly stuff that inspired this change. > My patch causes no changes on EEMBC for arm-none-eabi target. 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. I also checked the effect of my patch on GCC itself. My patch prevents one full scalarization of records with bit-field when compiling files under gcc/ with -O2. But there is no difference in the final assemblies. Regards, -- Jie Zhang CodeSourcery