This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC][2/2] Bitfield lowering


On Thu, 23 Jun 2011, Richard Guenther wrote:
> On Wed, Jun 22, 2011 at 10:24 PM, Hans-Peter Nilsson <hp@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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]