[M3devel] field accesses in m3cg?

[Jay K]

The more I look at this, the more I think we need to do it.
If we want to stop hacking optimizations off, use -O3, use configure -enable-checking.
The "failsafe" replacement for bitfields doesn't even work, though I'm trying to make it work.

Inevitably, for now, we are trading one set of deoptimizations vs. another.
For example, the heavy use of volatile was a big deoptimization that enabled
  "all" the rest to be done..at least from parse.c's point of view, though presumably
   volatile stopped a lot of code below.

Now I'm trying throwing around TREE_ADDRESSABLE, which I'm sure will
 also pessimize. We'll see. I'm not convinced that using ADDR_EXPR
 is equivalent to TREE_ADDRESSABLE. We'll see.

It wasn't enough to throw in TREE_ADDRESSABLE on load/store with offset != 0.
I'm trying it on all load/store now.

 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 3 Sep 2010 09:34:29 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] field accesses in m3cg?
>
> On 3 Sep 2010, at 07:28, Jay K wrote:
>
> >
> > Thoughts on exposing higher level "field load/store" in m3cg?
> > I'm wary of it currently.
> > Would rather do other stuff for now.
> >
> > It'd let the bitfield refs be replaced by something "proper".
> >
> > But it opens up more danger in terms of frontend/backend layout disagreement.
>
> I worry about this.
>
> >
> > - Jay
> >
> >
> >
> >
> >
>