On Thu, 23 Jun 2011, Richard Guenther wrote: > On Wed, Jun 22, 2011 at 10:24 PM, Hans-Peter Nilsson <h...@bitrange.com> > wrote: > > On Thu, 16 Jun 2011, Richard Guenther wrote: > > > >> This implements lowering a subset of COMPONENT_REFs with DECL_BIT_FIELD > >> FIELD_DECLs and BIT_FIELD_REFs - thus bitfield operations in general. > >> It lowers those to memory loads/stores that the (non-strict-align) target > >> is able to carry out, adjusting for the bit-field-ness by inserting > >> proper shifting and masking operations (just like expand does). > > > >> > >> Comments welcome - I wanted to post this before London to get > >> some input from people that won't attend. > > > > What does it do to code for targets with some kind of bitfield > > access insns? (insv, extv, various test insns taking a > > zero_extract or sign_extract argument) > > Do those usually work on memory operands?
I guess not. > If not, we can > lower to insv/extv like tree codes (BIT_FIELD_COMPOSE_EXPR, > BIT_FIELD_REF) that operate on registers. One goal of bitfield > lowering was to disallow memory operations in gimple that > are not addressable or are of non-byte-aligned size. Ah, ok. > > From the above "just like expand" I guess it's expected to be a > > no change, right? > > Well, I suppose the code in expand has to be adjusted to do the > proper things for those targets. The question is whether that's > going to be easy or not. > > So, do you know of a target that can do insv with a memory > target? Not from top of my head, no. brgds, H-P
