On Thu, Mar 5, 2015 at 10:03 AM, Bernd Edlinger <bernd.edlin...@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.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?
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. >>> >
