On Wed, 17 Jul 2013, 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:
>   <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.

I see noone else asked, so: How are volatile bitfields handled
or accesses to bitfields in structures declared volatile?

(A quick grep found no match for "volatil" in the patch; maybe
they're rejected by other means, but better double-check.  This
pass must not widen, narrow or combine such accesses and this
may or may not depend on the language standard.)

> 3. Modify trees accordingly.

brgds, H-P

Reply via email to