Re: [RFC] Don't completely scalarize a record if it contains bit-field (PR tree-optimization/45144)

[Jie Zhang <jie@codesourcery.com>]

On 07/31/2010 05:48 PM, Richard Guenther wrote:
> On Fri, Jul 30, 2010 at 6:09 PM, Jie Zhang<jie@codesourcery.com>  wrote:
>> PR tree-optimization/45144 shows an issue that SRA causes. I used
>> arm-none-eabi target as an example in PR tree-optimization/45144. But the
>> same issue can also been seen on x86_64-linux-gnu target using the same test
>> case in the PR.
>>
>> SRA completely scalarizes a small record. But when the record is used later
>> as a whole, GCC has to make the record out of the scalar parts. When the
>> record contains bit-fields, GCC generates ugly code to assemble the scalar
>> parts into a record.
>>
>> Until the aggregates copy propagation is implemented, I think it would
>> better to disable full scalarization for such records. The patch is
>> attached. It's bootstrapped on x86_64-linux-gnu and regression tested.
>>
>> Is it OK for now? We can remove it after aggregates copy propagation is
>> implemented.
>>
>> Will it be better to add bit-field check in type_consists_of_records_p
>> instead of using a new function "type_contains_bit_field_p"?
>
> The patch looks like a hack.  Can you instead make SRA treat the
> underlying type of bit-fields as the object for scalarization?
> I'm not 100% familiar with the internals, but IIRC SRA builds an
> access tree, so for each bitfield load/store the analysis phase should
> record an access of the underlying field covering all bits and
> a sub-access for the respective member.
>
Yes. It's a hack, but it's a hack to the hack for PR 42585. ;-) The fix 
for PR 42585 scalarize small records unconditionally, in hope that later 
passes can fix it up if the scalars are not used eventually. But for 
bit-fields, RTL combiner failed to do so. :-(

> Maybe Martin can weight in here.
>
Martin?


Regards,
-- 
Jie Zhang
CodeSourcery