This is the mail archive of the
mailing list for the GCC project.
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
On 8/31/06, Kenneth Zadeck <email@example.com> wrote:
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>> Even if we decide that we are going to process all of the functions in
>> one file at one time, we still have to have access to the functions that
>> are going to be inlined into the function being compiled. Getting at
>> those functions that are going to be inlined is where the double the i/o
>> arguement comes from.
> I understand -- but it's natural to expect that those functions will
> be clumped together. In a gigantic program, I expect there are going
> to be clumps of tightly connected object files, with relatively few
> connections between the clumps. So, you're likely to get good cache
> behavior for any per-object-file specific data that you need to access.
I just do not know. I assume that you are right, that there is some
clumping. But I am just no sure.
I just want to point out that this argument (okay cache locality) was
used as a reason the massive amount of open/seek/close behavior by
Subversion's FSFS filesystem is "a-ok".
It turns out not to be in practice, for a few reasons:
First, the syscall overhead ends up being pretty bad. Probably not as
bad in LTO as in Subversion (for obvious reasons), but you shouldn't
Second, and more importantly, on a network file system, the
open/seek/read calls to get at the cached data are going to be RPC