[llvm-dev] MLIR Buildbot configuration
Christian Kühnel via llvm-dev
llvm-dev at lists.llvm.org
Mon Aug 3 00:33:42 PDT 2020
happy to set it to batch mode, if someone tells me where to configure it :)
Otherwise we could also upgrade the machine from 16 to 32 cores, if you
would like to get more build results. Or do both...
On Sat, Aug 1, 2020 at 1:05 AM Stephen Neuendorffer via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +1 for batching. In practice it's probably more important that things get
> run for every MLIR checkin, and not necessarily for every LLVM checkin.
> On Fri, Jul 31, 2020 at 9:26 AM Mehdi AMINI via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>> Indeed there is quite a backlog here right now:
>> http://lab.llvm.org:8011/builders/mlir-windows and here
>> I agree that 17 hours of latency is likely too high to justify the
>> Note that the bots are doing `ninja` first followed by `ninja
>> check-mlir`: they likely build much more than they need: the build could be
>> faster by avoiding the first step.
>> On Fri, Jul 31, 2020 at 9:05 AM Johannes Doerfert <
>> johannesdoerfert at gmail.com> wrote:
>>> I broke the MLIR build yesterday and the two Flang bots told me about it
>>> pretty much right away. Yay!
>>> That is how I always thought the setup should work (modulo that we all
>>> try not to break builds).
>>> Today I got emails from an MLIR bot and I was a bit confused. I looked
>>> at the configuration of the two
>>> MLIR bots and it seems they test commits one by one, with the backlog
>>> that you would expect.
>>> I was wondering if my observation is correct and if this is the desired
>>> I don't necessarily think such a setup is bad but both MLIR bots run it
>>> this way, which might catch
>>> more problems but with a longer delay, unsure if it is worth it.
>>> I figured I bring this up but I'm fine when people don't see the need
>>> for change (or more bots).
>>> ~ Johannes
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev