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