[llvm-dev] llvm and clang are getting slower

[Xinliang David Li via llvm-dev]

See https://llvm.org/bugs/show_bug.cgi?id=17409

I believe much of the compile issues related to BlockFrequency computation
has been fixed by Cong's recent work to convert weight based interfaces to
BranchProbability based interfaces.  The other issue related to Spiller
probably still remains.

David

On Tue, Mar 8, 2016 at 1:13 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> On Tue, Mar 8, 2016 at 11:18 AM, Xinliang David Li via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Mar 8, 2016 at 10:55 AM, mats petersson via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> I have noticed that LLVM doesn't seem to "like" large functions, as a
>>> general rule. Admittedly, my experience is similar with gcc, so I'm not
>>> sure it's something that can be easily fixed. And I'm probably sounding
>>> like a broken record, because I have said this before.
>>>
>>> My experience is that the time it takes to compile something is growing
>>> above linear with size of function.
>>>
>>>
>> The number of BBs -- Kosyia can point you to the compile time bug that is
>> exposed by asan .
>>
>
> I believe we also have some superlinear behavior with BB size as well.
>
> -- Sean Silva
>
>
>>
>> David
>>
>>
>>
>>> Of course, the LLVM code is growing over time, both to support more
>>> features and to support more architectures, new processor types and
>>> instruction sets, at least of which will lead to larger functions in
>>> general [and this is the function "after inlining", so splitting small
>>> 'called once' functions out doesn't really help much].
>>>
>>> I will have a little play to see if I can identify more of a cuplrit [at
>>> the very least if it's "large basic blocks" or "large functions" that is
>>> the problem] - of course, this could be unrelated and irellevant to the
>>> problem Daniel is pointing at, and it may or may not be easily resolved...
>>>
>>> --
>>> Mats
>>>
>>> On 8 March 2016 at 18:42, Richard Smith via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> On Tue, Mar 8, 2016 at 8:13 AM, Rafael Espíndola
>>>> <llvm-dev at lists.llvm.org> wrote:
>>>> > I have just benchmarked building trunk llvm and clang in Debug,
>>>> > Release and LTO modes (see the attached scrip for the cmake lines).
>>>> >
>>>> > The compilers used were clang 3.5, 3.6, 3.7, 3.8 and trunk. In all
>>>> > cases I used the system libgcc and libstdc++.
>>>> >
>>>> > For release builds there is a monotonic increase in each version. From
>>>> > 163 minutes with 3.5 to 212 minutes with trunk. For comparison, gcc
>>>> > 5.3.2 takes 205 minutes.
>>>> >
>>>> > Debug and LTO show an improvement in 3.7, but have regressed again in
>>>> 3.8.
>>>>
>>>> I'm curious how these times divide across Clang and various parts of
>>>> LLVM; rerunning with -ftime-report and summing the numbers across all
>>>> compiles could be interesting.
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160308/de84cd5c/attachment.html>