[LLVMdev] [LLVM Dev] [Discussion] Function-based parallel LLVM backend code generation

[Chandler Carruth]

On Tue, Jul 16, 2013 at 1:46 PM, Xinliang David Li <xinliangli at gmail.com>wrote:

> On Tue, Jul 16, 2013 at 1:40 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> > On Tue, Jul 16, 2013 at 1:37 PM, Xinliang David Li <xinliangli at gmail.com
> >
> > wrote:
> >>
> >> On Tue, Jul 16, 2013 at 1:33 PM, Chandler Carruth <chandlerc at google.com
> >
> >> wrote:
> >> > On Tue, Jul 16, 2013 at 1:18 PM, Xinliang David Li
> >> > <xinliangli at gmail.com>
> >> > wrote:
> >> >>
> >> >> Ignoring FE time which can be fully parallelized and assuming 10%
> >> >> compile time is spent in serial module passes, 25% time is spent in
> >> >> CGSCC pass, the maximum speed up that can be gained by using function
> >> >> level parallelism is less than 3x.  Even adding support for parallel
> >> >> compilation for leaves of CG in CGSCC pass won't help too much -- the
> >> >> percentage of leaf functions is < 30% in large apps I have seen.
> >> >
> >> >
> >> > Can you clarify what you're basing these assumption on or how you
> >> > derived
> >> > your data?
> >> >
> >>
> >> Those numbers are purely speculative -- does Clang has an option to
> >> dump the time breakout of each passes such as -ftime-report in GCC?
> >
> >
> > We have the functionality... I thought we wired -ftime-report up to it?
> If
> > that doesn't work I'll have to go digging.
>
> I just checked -- it produces a flat report -- it would be nice to
> produce something similar to -debug-pass=Structure outputs.


Yea, improving the nested timing information and other improvements to
reflect the pass management structure are on my list for the significant
changes to the pass manager infrastructure I mentioned in my original
comments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130716/e42f8abf/attachment.html>