On Feb 12, 2007, at 10:42 PM, Basile STARYNKEVITCH wrote:
A big thanks for the explanation, which is something I partly
guessed, but which leaves me in a deep trouble :-)
Glad to turn on the flashlight so that you may see the hole. I hope
you know which way to dig now. :-)
I can't figure out why every GTY()-ed global data (extern or
static) should be overwritten at each PCH inclusion, but then maybe
I am wrong.
overwritten? No, that'd be wrong. If we supported it, and we don't,
because it is well past the point of diminishing returns, it would be
an unmap followed by an mmap. This should happen so that the state
is the state post the second include. I can't fathom why you'd think
that would be wrong, or slow, or anything else.
It seems to me that some such GTY-ed global data might explicily
want not to be reloaded,
You've not understood the basic design of PCH. It isn't there. If
you think it is there, you're thinking too hard. Data can't want to
stay around due to pch, because it can't know about pch. By not
knowing about pch, it can't fail to work, and it doesn't need any
testing (or much testing) to ensure it works well. There can't be
any obscure bugs in pch due in part to the design. Now, those that
follow it closely understand just how it deviates from this idealized
goal.
or maybe want to be always cleeared at each pch reload. However, I
am not sure there is any GTY tag for this.
There is no such rope, you can't hang yourself. :-)
I also don't understand at which point of the compilation is the
PCH dumped.
It is as if all the work that was done during
#include <foo.h>
wasn't done again and all that work just magically appeared done.
There is no limit on what that work is. For example, you want to run
an early optimization pass on the inline functions found in header
files and do inlining, have fun. You want to build a data flow
graph, have at it.
If you want to be at one with the code, set a breakpoint on the pch
writer and type up a few times. You can see just where it is called
from and that it has done. For C, it is done in pop_file_scope.
Everything done before pop_file_scope (after all of c_parse_file is
done) hits the pch file.
The idea is to front load as much processing as possible before that
point. This way, the cost is saved in every unit that uses the pch.
So, for example, let say there is an inline definition that we know
we will need and external version of, logically, it should be written
out before that point, so that we can just squirt the .s for it out
into the file .s file from the pch file.
For example, do PCH file contain Gimple-SSA trees (I would guess
yes) or
only Generic trees?
