[llvm-dev] llvm and clang are getting slower

[Sean Silva via llvm-dev]

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/f75b2e5b/attachment.html>