[llvm-dev] RFC: Large, especially super-linear, compile time regressions are bugs.

Bruno Cardoso Lopes via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 31 13:38:19 PDT 2016


On Thu, Mar 31, 2016 at 1:28 PM, Chandler Carruth via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> LLVM has a wonderful policy regarding broken commits: we revert to green. We
> ask that a test case be available within a reasonable time frame (preferably
> before, but some exceptions can be made), but otherwise we revert the
> offending patch, even if it contains nice features that people want, and
> keep the tree green. This is an awesome policy.
>
> I would like to suggest we adopt and follow the same policy for compile time
> regressions that are large, and especially for ones that are super-linear.
> As an example from the previous thread:

+1

> On Mon, Mar 14, 2016 at 12:14 PM Bruno Cardoso Lopes via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> > There is a possibility that r259673 could play a role here.
>> >
>> > For the buildSchedGraph() method, there is the -dag-maps-huge-region
>> > that
>> > has the default value of 1000. When I commited the patch, I was
>> > expecting
>> > people to lower this value as needed and also suggested this, but this
>> > has
>> > not happened. 1000 is very high, basically "unlimited".
>> >
>> > It would be interesting to see what results you get with e.g. -mllvm
>> > -dag-maps-huge-region=50. Of course, since this is a trade-off between
>> > compile time and scheduler freedom, some care should be taken before
>> > lowering this in trunk.
>>
>> Indeed we hit this internally, filed a PR:
>> https://llvm.org/bugs/show_bug.cgi?id=26940
>
>
> I think we should have rolled back r259673 as soon as the test case was
> available.

I agree, but since we didn't have a policy about it, I was kind of
unsure on what to do about it. Glad you begin this discussion :-)

> Thoughts?

Ideally it would be good to have more compile time sensitive
benchmarks on the test-suite to detect those. We're are working on
collecting what we have internally and upstream to help track the
results in a public way.

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


More information about the llvm-dev mailing list