This is the mail archive of the gcc@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: Skipping assembler when producing slim LTO files


On Thu, Sep 25, 2014 at 12:47 AM, Ian Lance Taylor <iant@google.com> wrote:
> Is that true even when TMPDIR is on a ram disk?  There's no obvious
> reason that it should be true in a parallel build.  Using -pipe
> effectively constrains communication between the compiler and the
> assembler to work in PIPE_BUF blocks.  Using TMPDIR introduces no such
> constraints, and in a big program a parallel build should obscure the
> fact that the compiler and assembler are serialized for each
> individual compilation unit.

As an aside, I think what matters is the capacity of the pipe rather
than PIPE_BUF. PIPE_BUF is the largest chunk that can be written
atomically, but since we don't have a case of multiple processes
writing to the same pipe(???), it doesn't matter. On a typical
x86(-64) Linux system, PIPE_BUF is 4k while the capacity is by default
64k (can be increased with fcntl(fd, F_SETPIPE_SZ, ...), perhaps worth
trying to see if it makes any difference?).

Still, it seems to me that making -pipe the default would make sense,
if the tradeoff appears to be a small loss in case when /tmp is a
tmpfs vs. a much larger gain when /tmp is a normal fs.


-- 
Janne Blomqvist


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