On Tue, Jul 30, 2013 at 4:47 PM, Zoran Jovanovic <zoran.jovano...@imgtec.com> wrote: > Thank you for the reply. > I am in the process of modifying the patch according to some comments > received. > Currently I am considering the usage of DECL_BIT_FIELD_REPRESENTATIVE. > I see that they can be used during analysis phase for deciding which accesses > can be merged - only accesses with same representative will be merged. > I have more dilemmas with usage of representatives for lowering. If my > understanding is correct bit field representative can only be associated to a > field declaration, and not to a BIT_FIELD_REF node. As a consequence > optimization 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 field declaration with appropriate bit size (equal to sum of bit sizes of > all merged bit field accesses) must be created and then corresponding bit > field representative could be attached. > Is my understanding correct? Is creating a new field declaration for every > 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.guent...@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 / doc > inside) > > Zoran Jovanovic <zoran.jovano...@imgtec.com> 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: >> <unnamed-unsigned:3> D.1351; >> <unnamed-unsigned:9> D.1350; >> <unnamed-unsigned:7> D.1349; >> D.1349_2 = p1_1(D)->f1; >> p2_3(D)->f1 = D.1349_2; >> D.1350_4 = p1_1(D)->f2; >> p2_3(D)->f2 = D.1350_4; >> D.1351_5 = p1_1(D)->f3; >> p2_3(D)->f3 = D.1351_5; >> >>Optimized code: >> <unnamed-unsigned:19> D.1358; >> D.1358_10 = BIT_FIELD_REF <*p1_1(D), 19, 13>; >> BIT_FIELD_REF <*p2_3(D), 19, 13> = 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 > optimizing - 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. > >
