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. Eric? Thanks, Richard. > > Thanks > Bernd. >
