Re: [PATCH] Add a new option "-ftree-bitfield-merge" (patch / doc inside)

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Jul 30, 2013 at 4:47 PM, Zoran Jovanovic
<Zoran.Jovanovic@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.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 / doc inside)
>
> Zoran Jovanovic <Zoran.Jovanovic@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.
>
>