Hi,
On Thu, 5 Mar 2015 09:52:54, Richard Biener wrote:
>
> On Thu, Mar 5, 2015 at 8:10 AM, Bernd Edlinger
> <bernd.edlin...@hotmail.de> wrote:
>> Hi,
>>
>> on ARM we have a code quality regression, because of the strict volatile
>> bitfields handing. The reason is that the current implementation directly
>> jumps to store_fixed_bit_field_1 which emits a sequence of and/or/shift
>> expressions. This turns out to be too complex for combine to figure out
>> the possibility to use a "bfi" instruction.
>>
>> But if -fno-strict-volatile-bitfields is used store_bit_field can use the
>> EP_insv code pattern, which results in "bfi" instructions.
>> The only problem is that that store_bit_field is free to use _any_ possible
>> access mode. But if we load the value first in a register, we can safely
>> use store_bit_field on the register and move the result back.
>>
>>
>> Boot-Strapped and regression-tested on Cortex-M3.
>>
>> OK for trunk?
>
> Hmm. As you also modify the no-strict-volatile-bitfield path I'm not sure
> you don't regress the case where EP_insv can work on memory. I agree
> that simplifying the strict-volatile-bitfield path to extract the memory
> within strict-volatile-bitfield constraints to a reg and then using the
> regular
> path is a good thing.
>
I tried _not_ to touch the no-strict-volatile-bitfield path.
Where did you see that?
Thanks
Bernd.
> Eric?
>
> Thanks,
> Richard.
>
>>
>> Thanks
>> Bernd.
>>
