[llvm] r216066 - Optimize ZERO_EXTEND and SIGN_EXTEND in both SelectionDAG Builder and type

[Jiangning Liu]

Hi Rafael,

Attached is that test case, but I can't see slowdown with it.

Thanks,
-Jiangning



2014-09-04 21:55 GMT+08:00 Rafael Espíndola <rafael.espindola at gmail.com>:

> Can you put that testcase somewhere?
>
> On 4 September 2014 01:19, Jiangning Liu <liujiangning1 at gmail.com> wrote:
> > Hi Rafael,
> >
> >
> > 2014-08-29 19:10 GMT+08:00 Rafael Espíndola <rafael.espindola at gmail.com
> >:
> >
> >> On 29 August 2014 05:16, Jiangning Liu <liujiangning1 at gmail.com> wrote:
> >> > Hi Rafael and Bob,
> >> >
> >> > The case you gave is really huge! :-)
> >>
> >> Yes, sorry, it is the LTO of clang :-)
> >>
> >> > I tried and it turned out it is not a infinite loop, and it can finish
> >> > in
> >> > ~70 minutes.
> >> >
> >> > I tried llc command line option -time-passes, and it shows
> >> >
> >> >
> >> >
> ==-------------------------------------------------------------------------===
> >> >                       ... Pass execution timing report ...
> >> >
> >> >
> ===-------------------------------------------------------------------------===
> >> >   Total Execution Time: 4125.4617 seconds (4124.7082 wall clock)
> >> >
> >> >    ---User Time---   --System Time--   --User+System--   ---Wall
> Time---
> >> > --- Name ---
> >> >   3911.0328 ( 95.1%)   8.5007 ( 65.8%)  3919.5335 ( 95.0%)  3920.7144
> (
> >> > 95.1%)  X86 DAG->DAG Instruction Selection
> >> >   47.5946 (  1.2%)   0.6397 (  5.0%)  48.2343 (  1.2%)  48.1823 (
> 1.2%)
> >> > Greedy Register Allocator
> >> >   16.7073 (  0.4%)   0.0244 (  0.2%)  16.7317 (  0.4%)  16.7890 (
> 0.4%)
> >> > Simple Register Coalescing
> >> >   11.6154 (  0.3%)   0.0164 (  0.1%)  11.6318 (  0.3%)  11.7178 (
> 0.3%)
> >> > Machine Instruction Scheduler
> >> >   10.8118 (  0.3%)   0.0677 (  0.5%)  10.8794 (  0.3%)  10.3740 (
> 0.3%)
> >> > Loop Strength Reduction
> >> >
> >> > So the problem is around "X86 DAG->DAG Instruction Selection".
> >> >
> >> > I tried to capture "hot" sports using debugger, but I failed, and it
> >> > seems
> >> > the time is accumulated somewhere.
> >> >
> >> > Do you have any suggestions?
> >>
> >> You can try running llvm-extract with every function and then running
> >> llc on the result (which will have only one function). Hopefully you
> >> will find a much smaller testcase that way.
> >
> >
> > Thanks for your suggestion. I tried this method, and successfully
> extracted
> > 27041 functions from that huge file. However, I failed to reproduce a
> small
> > case containing a single function which can reproduce the slowdown. The
> > slowest function I find is
> >
> _ZN5clang15StmtVisitorBaseINS_8make_ptrENS_13ASTStmtWriterEvE5VisitEPNS_4StmtE.bc,
> > but it can finish in 16 seconds on my x86 box.
> >
> > So it seems there are some module passes triggering the slowdown issue...
> >
> > Thanks,
> > -Jiangning
> >
> >>
> >>
> >> > And I'm wondering if this is a x86 specific issue or the slowdown can
> >> > also
> >> > exposed for other targets like aarch64?
> >>
> >> Hard to tell without a smaller testcase.
> >>
> >> Cheers,
> >> Rafael
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140905/350c5976/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _ZN5clang15StmtVisitorBaseINS_8make_ptrENS_13ASTStmtWriterEvE5VisitEPNS_4StmtE.bc.tgz
Type: application/x-gzip
Size: 404088 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140905/350c5976/attachment.bin>