[llvm-commits] [llvm] r76615 - in /llvm/trunk: include/llvm/CodeGen/LiveIntervalAnalysis.h lib/CodeGen/LiveIntervalAnalysis.cpp

[Evan Cheng]

On Jul 23, 2009, at 12:00 PM, David Greene wrote:

> On Thursday 23 July 2009 03:35, Daniel Dunbar wrote:
>> On Wed, Jul 22, 2009 at 3:00 PM, David Greene<dag at cray.com> wrote:
>>> On Wednesday 22 July 2009 16:32, Evan Cheng wrote:
>>>> On Jul 22, 2009, at 12:49 PM, Daniel Dunbar wrote:
>>>
>>> I completely agree.  But the version you tested was before the  
>>> various
>>> performance enhancements.  Do you know what it looks like now?
>>>  Unfortunately I can't test right now because my build is broken.
>>
>> I haven't seen a drop corresponding to the increase yet. The results
>> of our regular nightlytester are archived on llvm-testresults
>> (although they are not in the llvm.org database). I attached a
>> comparison of the latest run (2 hours ago) versus the last run before
>> your patch. This looks pretty close to the original regression, see
>> original delta here:
>> http://lists.cs.uiuc.edu/pipermail/llvm-testresults/2009-July/016427.html
>
> The report makes no sense to me.  What are the units?  Compile  
> time?  Binary
> size?  I assume compile time but that's not stated anywhere in the  
> report.

Yes, it's compile time.

>
> I've had this problem with the nightly web page before.  The various  
> things
> being tested aren't explained at all.  I don't know what "CBE  
> significant
> changes" means, nor "LLC significant changes."  *What's* changing?
>
> Is it compile time for all benchmarks, or just a subset?  Which ones  
> should I
> be looking at?

Pretty much the entire suite.

>
> Given that Evan reported a 30% increase with my original patch,  I'd  
> say the
> compile time hit has lessened quite a bit (30% vs. 8% for most  
> codes).  The
> 8% could easily be explained by printing line nubmer comments on every
> single asm line.  Some things even got faster.

 From what I can tell, with llc -verbose-asm=false does *not* turn off  
the line number comments. That seems wrong and is probably  
contributing to the compile time increase. That means it will cause  
compile time regression for folks who use llvm-gcc to compile directly  
to .s file.

I don't have time to do the experiment. But if you take a large  
bitcode file, run llc on it and measure the time. And then do the same  
experiment after backing out your changes, you should see a difference.

Evan

>
> Or am I reading this incorrectly?
>
>                                -Dave
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits