Re: Apple's PFE for GCC is now available

[Devang Patel <dpatel at apple dot com>]

On Wednesday, July 31, 2002, at 09:19  AM, Daniel Berlin wrote:

> On Wednesday, July 31, 2002, at 12:04  PM, Mike Stump wrote:
>
> > On Tuesday, July 30, 2002, at 11:43 PM, Neil Booth wrote:
> >
> > > > Finally, if you're wondering how this relates to the PCH branch, 
> > > > it's
> > > > being actively discussed.  PFE has both pluses and minuses relative 
> > > > to
> > > > the current PCH work, and ideally we'll be able to use both in 
> > > > coming
> > > > up with superior precompiled header support for FSF GCC.
> > > Where is it being actively discussed?  It's a shame this stuff isn't
> > > out in the open; I'd like to know what the plans are as I have (had)
> > > ideas of my own.
> > This is the right place.  This is the place where we are discussing 
> > it.
> >
> > The plan is to make gcc/g+ 6x faster.  Exactly how we do that, is up 
> > for discussion.  We have an initial implementation that gets us there 
> > that we are using in our production compiler.  If it meets the 
> > various standards for the tree, would be nice to get it into the 
> > tree.  Once in, we can then refine it further.
> (A note: I've been following PFE since it's existed in apple's tree, 
> so I'm intimately familiar with it.)
> PFE's implementation, as it stands, is somewhat invasive, with the 
> GGC_ALLOC macro, etc.
> While I understand many of these invasions are necessary to restore 
> the state properly (like intercepting the debug hooks), there is one 
> invasion that *should* be completely unnecessary if PFE was in the 
> mainline.
We have taken great care (with lots of extra pain) to make sure that we 
can continue
importing from FSF while we continue to work on PFE (and do not disturb 
strict Mac OS X
schedule). Most of the macro invasion is to keep things separate so 
that with one
configure switch we can entirely disable or enable PFE in gcc3. If PFE 
is accepted
in FSF, most of it can go away.

PFE implementation code is everywhere but it is, IMO, very clean and 
separate.
For example,
- Many places we are using PFE_MALLOC macro instead of xmalloc () call.
  Which is just doing the job of diverting to actual xmalloc or PFE 
mem. manager.
- All PFE operations are controlled by #ifdef PFE. (again no need to 
keep this
  once PFE goes into FSF)
- All new routines required for PFE are always appended at the end of 
source file.
- All pfe routines use pfe_ prefix and many place it can be actually 
replaced
  and/or merged with original routine.
- We have gone through lots of pain, because otherwise we would need to
  reorganize FSF source in minor way. We refrained to do that, because 
it would
  have made our regular FSF imports very difficult.
- PFE memory manager and tree walker is kept in separate directory 
gcc/pfe.
  These two components, in some sense collide/replicate, with garbage 
collector and
other tree walkers. It would be nice, if people more familiar with 
garbage
collector and other tree walkers look into these and see what we are 
trying
to do. The freeze/throw tree walk usage is somewhat different than other
tree walks (even we had to rewrite our own tree walker to get it 
correct)
so, in my opinion, we can not just replace it with other tree walker 
unless
we update other tree walks. But I can be wrong.

In any case, more experienced eye balls can help us to identify what
we missed and what we could have done in better way. And we are ready 
to do
all necessary to have one real good precomp model in FSF gcc.

In short, I just wanted to say that some of the code clutter is not 
necessary
and it is there because it would be easier to see what PFE is trying to 
do
and ultimately make it easier to merge with FSF.

- Devang