[LLVMdev] llc is taking a long time at -O1 to convert *.bc to *.s

[Chad Rosier]

Sreekumar,
Without a test case, we really can't determine if this is expected behavior.  Certainly, we'd prefer -O1 compile-times to be relatively fast.  Have you tried this with a ToT clang?  If you're still seeing such poor performance then I suggest filing a bug (http://llvm.org/bugs).  Please include a test case and the command line arguments to reproduce the problem.  I believe ToT is compatible with 3.0 bitcode files, so you could just submit your bitcode file.

 Chad



On Feb 2, 2012, at 11:03 PM, "Kodakara, Sreekumar V" <sreekumar.v.kodakara at intel.com> wrote:

> Hi All,
>  
> I am using llvm-3.0 release version for compiling some files. I have a cpp file on which I did a few custom passes. After that I used llc to convert the *.bc file to *.s file at –O1 optimization level. llc took ~2630 seconds to perform this conversion. I timed llc and these are the top three passes that is taking most of the time.
>  
>  ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
>   1816.1735 ( 77.8%)  23.3215 ( 69.7%)  1839.4950 ( 77.6%)  1839.4132 ( 77.6%)  Simple Register Coalescing
>   493.5948 ( 21.1%)   9.1846 ( 27.4%)  502.7794 ( 21.2%)  502.7681 ( 21.2%)  X86 DAG->DAG Instruction Selection
>    5.7244 (  0.2%)   0.0000 (  0.0%)   5.7244 (  0.2%)   5.7204 (  0.2%)  Machine Instruction LICM
>  
> I am running this in a fairly new Xeon server. Furthermore, at –O0, llc takes less than 20 seconds to complete. Is this behavior expected and is there a way to disable Simple Register Coalescing pass without switching to –O0 optimization level to get around this problem?
>  
> Thanks
> Sreekumar
>  
>  
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120203/064f68ea/attachment.html>