[llvm] r213898 - [SDAG] Introduce a combined set to the DAG combiner which tracks nodes

[Bruno Cardoso Lopes]

About testcases, this is what I get for CPU2006/403.gcc/src/combine.c:

== 403.gcc-x86-combine.c-O3, 2% clang compile time increase.
Pass Name, [r213874] Time Share, [r213910] Time Share, Relative Increase
DAG Combining 2, 7.85%, 9.35%, 1.1911
DAG Combining 1, 15.20%, 17.95%, 1.1809
DAG Combining after legalize types, 7.50%, 8.75%, 1.1667
X86 DAG->DAG Instruction Selection, 24.00%, 25.25%, 1.0521

== 403.gcc-armv7-combine.c-O3, 3% clang compile time increase.
Pass Name, [r213874] Time Share, [r213910] Time Share, Relative Increase
DAG Combining 2, 6.80%, 8.90%, 1.3088
DAG Combining 1, 16.30%, 18.70%, 1.1472
ARM Instruction Selection, 25.70%, 26.65%, 1.0370

== 403.gcc-armv7-combine.c-Os-g, 3% clang compile time increase.
Pass Name, [r213874] Time Share, [r213910] Time Share, Relative Increase
DAG Combining 2, 6.70%, 8.80%, 1.3134
DAG Combining 1, 16.00%, 18.40%, 1.1500
ARM Instruction Selection, 21.80%, 22.70%, 1.0413

P.S. this is the median result of 5 runs for each entry above, where
combine.c is compiled 10x each time. There wasn't much fluctuation.

On Fri, Aug 22, 2014 at 3:53 PM, Bruno Cardoso Lopes
<bruno.cardoso at gmail.com> wrote:
> Hi Chandler,
>
> I measured the regression from r213910 against r213874, there are
> about 20 llvm commits in the gap. From the measured regressions, the
> most affected passes are DAG Combining 2, DAG Combining after legalize
> types and DAG Combining 1.
>
> The only commits touching such DAG passes is this one (r213898) and
> there is also another one from you (r213897), but the former looks
> more likely.
>
> On Fri, Aug 22, 2014 at 3:12 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
>>
>> On Fri, Aug 22, 2014 at 10:00 AM, Bob Wilson <bob.wilson at apple.com> wrote:
>>>
>>> > I've tried to check for compile-time regressions here by running llc
>>> > over a merged (but not LTO-ed) clang bitcode file and observed at most
>>> > a 3% slowdown in llc. Given that this is essentially a worst case (none
>>> > of opt or clang are running at this phase) I think this is tolerable.
>>> > The actual LTO case should be even less costly, and the cost in normal
>>> > compilation should be negligible.
>>>
>>> We’re seeing a larger impact, with widespread regressions in the range of
>>> 2-4% on overall clang compile times (non-LTO), including the optimization
>>> time. Is there any way you can think of to speed this up?
>>
>>
>> How confident are you that it is this patch? I'm not questioning the
>> regression -- we've been seeing some as well, just curious whether its
>> *definitely* this patch or just something recent and this patch called out
>> the possibility...
>>
>> As for speeding it up, I have ideas, but it is very hard. the SDAG data
>> structures make everything really, really slow.
>>
>> If it is definitely this patch, it would be helpful to have representative
>> test cases in IR form. When benchmarking the compile time myself, my test
>> cases showed overall compile time regressions in the 1% and smaller range
>> (below the noise floor of my measurements honestly).
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc



-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc