This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Add a new option "-ftree-bitfield-merge" (patch / doc inside)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Zoran Jovanovic <Zoran dot Jovanovic at imgtec dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Petar Jovanovic <Petar dot Jovanovic at imgtec dot com>
- Date: Tue, 27 Aug 2013 13:32:23 +0200
- Subject: Re: [PATCH] Add a new option "-ftree-bitfield-merge" (patch / doc inside)
- Authentication-results: sourceware.org; auth=none
- References: <386B40EC5E8DBF459FD11A754D868AD922E31112 at BADAG02 dot ba dot imgtec dot org> <ffbcb5fb-6c51-4cf2-aea2-3c98874707a8 at email dot android dot com> <386B40EC5E8DBF459FD11A754D868AD922E31E3E at BADAG02 dot ba dot imgtec dot org>
On Tue, Jul 30, 2013 at 4:47 PM, Zoran Jovanovic
> 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
> Zoran Jovanovic
> From: Richard Biener [email@example.com]
> Sent: Thursday, July 18, 2013 11:31 AM
> To: Zoran Jovanovic; firstname.lastname@example.org
> Cc: Petar Jovanovic
> Subject: Re: [PATCH] Add a new option "-ftree-bitfield-merge" (patch / doc inside)
> Zoran Jovanovic <Zoran.Jovanovic@imgtec.com> wrote:
>>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.
>> <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;
>> <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
>>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.