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] Fix PR52977


On Mon, 16 Apr 2012, Diego Novillo wrote:

> On Mon, Apr 16, 2012 at 10:23, Richard Guenther <rguenther@suse.de> wrote:
> > On Mon, 16 Apr 2012, Steven Bosscher wrote:
> >
> >> On Mon, Apr 16, 2012 at 3:19 PM, Richard Guenther <rguenther@suse.de> wrote:
> >> >
> >> > This fixes PR52977 - for PCH to work with its pointer relocation code
> >> > we have to avoid dereferencing pointers to compute array lengths
> >> > in structures. ?So we have to unfortunately keep duplicated info about
> >> > VECTOR_CST vector lengths.
> >>
> >> Maybe add a FIXME for when pph hits trunk?
> >
> > I'm not sure PPH will replace PCH - will it?
> 
> In theory, it may.  But it's not in the immediate plans.
> 
> The big thing that PCH has going for it is load speed.  PCH is almost
> instantaneous, PPH isn't.  A 1Gb PCH file can be restored in <1s, the
> corresponding PPH file needs ~8s to restore.  The implementation can
> still be tuned for performance, but it will never be as fast as a
> couple of mmap operations.
> 
> PPH is a much smaller representation (that 1Gb PCH file can be
> represented in <400Mb in PPH) and more flexible (almost any arbitrary
> subset of headers can be turned into separate PPH images).
> 
> So, it's not clear whether we will want to replace PCH with PPH.
> Flexibility costs raw performance.  If the performance gap can be
> bridged, we may want to consider it in the future.

Well, the number one advantage of replacing PCH is that it would kill
the current PCH implementation which is tied to our garbage collector...

Richard.

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