This is the mail archive of the
mailing list for the GCC project.
Re: Skipping assembler when producing slim LTO files
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, Jan Hubicka <hubicka at ucw dot cz>, Andi Kleen <andi at firstfloor dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 24 Sep 2014 23:51:25 +0200
- Subject: Re: Skipping assembler when producing slim LTO files
- Authentication-results: sourceware.org; auth=none
- References: <20140924054651 dot GB5371 at kam dot mff dot cuni dot cz> <878ul96pnx dot fsf at tassilo dot jf dot intel dot com> <CAKOQZ8zCs8ZjGP3JWw6HVNXGS0junJn1BuvnMXmK8Ou8WHEnvg at mail dot gmail dot com> <20140924161906 dot GA26922 at atrey dot karlin dot mff dot cuni dot cz> <20140924163227 dot GB26922 at atrey dot karlin dot mff dot cuni dot cz> <CABu31nO248rEg2xmj1MYvt-p3Y7+EbNu6U-UV6aTeMzxbiZ_Pw at mail dot gmail dot com> <CAKOQZ8ytc5nevvq2AAX4TwztWopenhF5Ah9k_+zubb+-Z1JaYQ at mail dot gmail dot com>
> On Wed, Sep 24, 2014 at 10:04 AM, Steven Bosscher <email@example.com> wrote:
> > On Wed, Sep 24, 2014 at 6:32 PM, Jan Hubicka <firstname.lastname@example.org> wrote:
> >> Libreoffice shows that GCC needs about twice as much of system time. According
> >> to profiles, good part is the ugly way we pass stuff down to assembler and
> >> other part is memory use during the copmilation stage.
> > Are you using -pipe? AFAIR this still isn't the default, even on
> > GNU/Linux, but it is typically a lot faster than without.
> 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.
Actually I mount /tmp as tmpfs, so this should not be an issue.
Oviously for slim LTO we get more benefits from outputting binary data directly
rather than spending time to printf and scanf them ;)