From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8293 invoked by alias); 27 Aug 2013 11:32:28 -0000 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 Received: (qmail 8281 invoked by uid 89); 27 Aug 2013 11:32:28 -0000 Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com) (209.85.212.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 27 Aug 2013 11:32:28 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KHOP_THREADED,NO_RELAYS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f181.google.com Received: by mail-wi0-f181.google.com with SMTP id ex4so1917774wid.2 for ; Tue, 27 Aug 2013 04:32:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.183.108 with SMTP id el12mr10924847wic.55.1377603143319; Tue, 27 Aug 2013 04:32:23 -0700 (PDT) Received: by 10.194.200.74 with HTTP; Tue, 27 Aug 2013 04:32:23 -0700 (PDT) In-Reply-To: <386B40EC5E8DBF459FD11A754D868AD922E31E3E@BADAG02.ba.imgtec.org> References: <386B40EC5E8DBF459FD11A754D868AD922E31112@BADAG02.ba.imgtec.org> <386B40EC5E8DBF459FD11A754D868AD922E31E3E@BADAG02.ba.imgtec.org> Date: Tue, 27 Aug 2013 11:33:00 -0000 Message-ID: Subject: Re: [PATCH] Add a new option "-ftree-bitfield-merge" (patch / doc inside) From: Richard Biener To: Zoran Jovanovic Cc: "gcc-patches@gcc.gnu.org" , Petar Jovanovic Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-08/txt/msg01574.txt.bz2 On Tue, Jul 30, 2013 at 4:47 PM, Zoran Jovanovic wrote: > Thank you for the reply. > I am in the process of modifying the patch according to some comments rec= eived. > Currently I am considering the usage of DECL_BIT_FIELD_REPRESENTATIVE. > I see that they can be used during analysis phase for deciding which acce= sses can be merged - only accesses with same representative will be merged. > I have more dilemmas with usage of representatives for lowering. If my un= derstanding is correct bit field representative can only be associated to a= field declaration, and not to a BIT_FIELD_REF node. As a consequence optim= ization must use COMPONENT_REF to model new bit field access (which should = be an equivalent of several merged accesses). To use COMPONENT_REF a new fi= eld declaration with appropriate bit size (equal to sum of bit sizes of all= merged bit field accesses) must be created and then corresponding bit fiel= d representative could be attached. > Is my understanding correct? Is creating a new field declaration for ever= y set of merged bit field accesses acceptable? You should just use the DECL_BIT_FIELD_REPRESENTATIVE FIELD_DECL, not create any new FIELD_DECLs. Also you can use BIT_FIELD_REFs but you need to query the proper bit position / size from the DECL_BIT_FIELD_REPRESENTATIVE FIELD_DECL. Using the COMPONENT_REF is better though, I think. Full patch queued for review (but you might want to update it to not create= new FIELD_DECLs). Richard. > > Regards, > Zoran Jovanovic > > ________________________________________ > From: Richard Biener [richard.guenther@gmail.com] > Sent: Thursday, July 18, 2013 11:31 AM > To: Zoran Jovanovic; gcc-patches@gcc.gnu.org > Cc: Petar Jovanovic > Subject: Re: [PATCH] Add a new option "-ftree-bitfield-merge" (patch / do= c inside) > > Zoran Jovanovic wrote: > >>Hello, >>This patch adds new optimization pass that combines several adjacent >>bit field accesses that copy values from one memory location to another >>into single bit field access. >> >>Example: >> >>Original code: >> D.1351; >> D.1350; >> D.1349; >> D.1349_2 =3D p1_1(D)->f1; >> p2_3(D)->f1 =3D D.1349_2; >> D.1350_4 =3D p1_1(D)->f2; >> p2_3(D)->f2 =3D D.1350_4; >> D.1351_5 =3D p1_1(D)->f3; >> p2_3(D)->f3 =3D D.1351_5; >> >>Optimized code: >> D.1358; >> D.1358_10 =3D BIT_FIELD_REF <*p1_1(D), 19, 13>; >> BIT_FIELD_REF <*p2_3(D), 19, 13> =3D D.1358_10; >> >>Algorithm works on basic block level and consists of following 3 major >>steps: >>1. Go trough basic block statements list. If there are statement pairs >>that implement copy of bit field content from one memory location to >>another record statements pointers and other necessary data in >>corresponding data structure. >>2. Identify records that represent adjacent bit field accesses and mark >>them as merged. >>3. Modify trees accordingly. > > All this should use BITFIELD_REPRESENTATIVE both to decide what accesses = are related and for the lowering. This makes sure to honor the appropriate = memory models. > > In theory only lowering is necessary and FRE and DSE will do the job of o= ptimizing - also properly accounting for alias issues that Joseph mentions.= The lowering and analysis is strongly related to SRA So I don't believe we= want a new pass for this. > > Richard. > >