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: Zoran Jovanovic <Zoran dot Jovanovic at imgtec dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Cc: Petar Jovanovic <Petar dot Jovanovic at imgtec dot com>
- Date: Tue, 30 Jul 2013 14:47:56 +0000
- Subject: RE: [PATCH] Add a new option "-ftree-bitfield-merge" (patch / doc inside)
- References: <386B40EC5E8DBF459FD11A754D868AD922E31112 at BADAG02 dot ba dot imgtec dot org>,<ffbcb5fb-6c51-4cf2-aea2-3c98874707a8 at email dot android dot com>
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?
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.