On Tue, Apr 12, 2011 at 12:44 PM, Mike Stump <mikest...@comcast.net> wrote: >> - If objects stored in PCH have pointers pointing outside of >> PCH-able/GC-managed memory, these become wild pointers on PCH read even with >> GTY((skip)) applied properly. However, not all GTY((skip)) pointers point >> outside of PCH-able memory, so I have overloaded GTY((deletable)) option to >> reset such fields to NULL on PCH write. This is only a part of the fix as >> logic needs to be reviewed what to do with these NULLs after the PCH read. >> In case of DECL_RTL, the NULL in the field causes re-creation of rtx anew, >> which I think is the right thing. > > Not an example of a warm fuzzy. When you combine this with the entire idea > of PCH, and that is to slosh to disk and back, the entire state of the > compiler, essentially, unmodified, we run into a conceptual gap. Now, why > did PCH have that design, so that we could limit the number of pch bugs and > come up with a robust design that just works. This is a useful property.
I've debuged PCH bugs and they were usually a _result_ of the poor design. Missing GTY on non-pointer objects for example. There is nothing robust about the design of PCH and it certainly does not "just work". But, two things: 1. RTL and PCH should be completely separate. No DECL_RTL should ever end up in a PCH because DECL_RTL is not created in the front end (or should not be, it'd be a bug) 2. PCH as we know it will probably be gone soon (Google's pph stuff) Ciao! Steven
