Re: [PATCH] Fix PR rtl-optimization/65067

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

On Thu, Mar 5, 2015 at 10:03 AM, Bernd Edlinger
<bernd.edlinger@hotmail.de> wrote:
> Hi,
>
> On Thu, 5 Mar 2015 09:52:54, Richard Biener wrote:
>>
>> On Thu, Mar 5, 2015 at 8:10 AM, Bernd Edlinger
>> <bernd.edlinger@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?

You changed store_bit_field - ah, sorry, context missing in the patch.  So yes,
the patch is ok.

Thanks,
Richard.

> Thanks
> Bernd.
>
>> Eric?
>>
>> Thanks,
>> Richard.
>>
>>>
>>> Thanks
>>> Bernd.
>>>
>