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

[Bob Wilson]

> On Aug 22, 2014, at 11:53 AM, 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.

It’s possible that regression is more pronounced when building with LTO.

Bruno, just to be sure, can you build clang with LTO where the only difference is this change to try to confirm that this patch is responsible?

> 
> 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