[llvm-dev] Buildbots timing out on full builds

Fri May 26 01:10:14 PDT 2017

Ok, that sounds reasonable. I'm happy to test more patches for you
when they're ready.

On 25 May 2017 at 17:39, Daniel Sanders <daniel_l_sanders at apple.com> wrote:
> Thanks for trying that patch. I agree that 34 mins still isn't good enough but we're heading in the right direction.
>
> Changing the partitioning predicate to the instruction opcode rather than the number of operands in the top-level instruction will hopefully cut it down further. I also have a patch that shaves a small amount off of the compile-time by replacing the various LLT::scalar()/LLT::vector() calls with references to LLT objects that were created in advance. I tried something similar with the getRegBankForRegClass() but I haven't written that as a patch yet since that one requires some refactors to get access to a mapping that RegisterBankEmitter.cpp knows. In my experiment I edited this information into AArchGenGlobalISel.inc by hand.
>
> I think the real solution is to convert the generated C++ to the state-machine that we intended to end up with. I don't think we'll be able to put it off much longer given that we're hitting compile-time problems when we can only import 25% of the rules. That said, I have a couple more nearly-finished patches I'd like to get in before we introduce the state machine. Hopefully, the above tricks will be enough to save me a re-write.
>
>> On 25 May 2017, at 16:11, Diana Picus <diana.picus at linaro.org> wrote:
>>
>> Hi Daniel,
>>
>> I built r303542, then applied your patch and built again and it still takes
>> real    34m30.279s
>> user    84m36.553s
>> sys     0m58.372s
>>
>> This is better than the 50m I saw before, but I think we should try to
>> make it a bit faster. Do you have any other ideas to make it work?
>>
>> Thanks,
>> Diana
>>
>>
>> On 22 May 2017 at 11:22, Diana Picus <diana.picus at linaro.org> wrote:
>>> Hi Daniel,
>>>
>>> I did your experiment on a TK1 machine (same as the bots) and for r303258 I get:
>>> real    18m28.882s
>>> user    35m37.091s
>>> sys     0m44.726s
>>>
>>> and for r303259:
>>> real    50m52.048s
>>> user    88m25.473s
>>> sys     0m46.548s
>>>
>>> If I can help investigate, please let me know, otherwise we can just
>>> try your fixes and see how they affect compilation time.
>>>
>>> Thanks,
>>> Diana
>>>
>>> On 22 May 2017 at 10:49, Daniel Sanders <daniel_l_sanders at apple.com> wrote:
>>>> r303341 is the re-commit of the r303259 which tripled the number of rules
>>>> that can be imported into GlobalISel from SelectionDAG. A compile time
>>>> regression is to be expected but when I looked into it I found it was ~25s
>>>> on my machine for the whole incremental build rather than the ~12mins you
>>>> are seeing. I'll take another look.
>>>>
>>>> I'm aware of a couple easy improvements we could make to the way the
>>>> importer works. I was leaving them until we change it over to a state
>>>> machine but the most obvious is to group rules by their top-level gMIR
>>>> instruction. This would reduce the cost of the std::sort that handles the
>>>> rule priorities in generating the source file and will also make it simpler
>>>> for the compiler to compile it.
>>>>
>>>>
>>>> On 21 May 2017, at 11:16, Vitaly Buka <vitalybuka at google.com> wrote:
>>>>
>>>> It must be r303341, I commented on corresponding llvm-commits thread.
>>>>
>>>> On Fri, May 19, 2017 at 7:34 AM, Diana Picus via llvm-dev
>>>> <llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>> Ok, thanks. I'll try to do a bisect next week to see if I can find it.
>>>>>
>>>>> Cheers,
>>>>> Diana
>>>>>
>>>>> On 19 May 2017 at 16:29, Daniel Sanders <daniel_l_sanders at apple.com>
>>>>> wrote:
>>>>>>
>>>>>>> On 19 May 2017, at 14:54, Daniel Sanders via llvm-dev
>>>>>>> <llvm-dev at lists.llvm.org> wrote:
>>>>>>>
>>>>>>> r303259 will have increased compile-time since it tripled the number of
>>>>>>> importable
>>>>>>> SelectionDAG rules but a quick measurement building the affected file:
>>>>>>>   ninja
>>>>>>> lib/Target/<Target>/CMakeFiles/LLVM<Target>CodeGen.dir/<Target>InstructionSelector.cpp.o
>>>>>>> for both ARM and AArch64 didn't show a significant increase. I'll check
>>>>>>> whether
>>>>>>> it made a different to linking.
>>>>>>
>>>>>> I don't think it's r303259. Starting with a fully built r303259, then
>>>>>> updating to r303258 and running 'ninja' gives me:
>>>>>>        real    2m28.273s
>>>>>>        user    13m23.171s
>>>>>>        sys     0m47.725s
>>>>>> then updating to r303259 and running 'ninja' again gives me:
>>>>>>        real    2m19.052s
>>>>>>        user    13m38.802s
>>>>>>        sys     0m44.551s
>>>>>>
>>>>>>> sanitizer-x86_64-linux-fast also timed out after one of my commits this
>>>>>>> morning.
>>>>>>>
>>>>>>>> On 19 May 2017, at 14:14, Diana Picus <diana.picus at linaro.org> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We've noticed that recently some of our bots (mostly
>>>>>>>> clang-cmake-armv7-a15 and clang-cmake-thumbv7-a15) started timing out
>>>>>>>> whenever someone commits a change to TableGen:
>>>>>>>>
>>>>>>>> r303418:
>>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7268
>>>>>>>> r303346:
>>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7242
>>>>>>>> r303341:
>>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7239
>>>>>>>> r303259:
>>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7198
>>>>>>>>
>>>>>>>> TableGen changes before that (I checked about 3-4 of them) don't have
>>>>>>>> this problem:
>>>>>>>> r303253:
>>>>>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7197
>>>>>>>>
>>>>>>>> That one in particular actually finishes the whole build in 635s,
>>>>>>>> which is only a bit over 50% of the timeout limit (1200s). So, between
>>>>>>>> r303253 and now, something happened that made full builds
>>>>>>>> significantly slower. Does anyone have any idea what that might have
>>>>>>>> been? Also, has anyone noticed this on other bots?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Diana
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>>>
>>>>
>