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

[Justin Bogner via llvm-dev]

Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 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:
>
> 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.
>
> Thoughts?

+1. Reverting is easy when a commit is fresh, but gets rapidly more
difficult as other changes (related or not) come after it, whereas
re-applying a commit later is usually straightforward.

Keeping the top of tree compiler in good shape improves everyone's
lives.