[llvm-dev] Build status expectations for experimental targets

[Dylan McKay via llvm-dev]

Sorry, I don't think I was clear enough.

When I make AVR the default target triple, most of the generic CodeGen
tests pass, but some don't. The easiest solution was to make X86 the
default target so the generic CodeGen tests run under it, and that way the
AVR specific tests still run.

The bug causing the tests to fail is not because the default target hasn't
been built, it's an assertion error hit inside the AVR ISel code.

Once the generic suite passes, I will make AVR the default target on the
builders.

On Sat, Feb 4, 2017 at 12:17 PM, Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> On Feb 3, 2017, at 5:15 PM, Mehdi Amini via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
> On Feb 3, 2017, at 5:14 PM, Matthias Braun <mbraun at apple.com> wrote:
>
>
> On Feb 3, 2017, at 12:45 PM, Dylan McKay via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> The builder isn’t marked as experimental so I think the expectation is
> that people keep it green and contact the bot owner if they need help
> figuring out why their change makes it red. That said, it sounds a bit odd
> to have a non-experimental builder for an experimental backend.
>
> I see. I had followed the generic How to add a builder
> <http://llvm.org/docs/HowToAddABuilder.html> docs, which doesn’t mention
> the concept of an experimental buildbot. I’ll send a patch to mention it.
>
> If you want to do the same, then you’ll need to add an
> InformativeMailNotifier to http://llvm.org/svn/llvm-
> project/zorg/trunk/buildbot/osuosl/master/config/status.py.
>
> Nice! Exactly what I was looking for.
>
> If we would believe the AVR backend is stable enough, such that users can
> rely on it and such that other developers are unlikely to trigger bugs in
> the AVR backend, the AVR backend should most likely be promoted to a stable
> backend.
>
> In general, I’ve found that almost all of the time that the AVR build
> breaks, it’s been something pretty small which also caused a bunch of other
> targets to fail also, which I suppose is a good sign. On the topic, I plan
> on following up on promoting the backend to stable once the current effort
> of enabling AVR in Rust is complete and we’ve ironed out any bugs found in
> usage.
>
> As a result of this, I would also expect buildbots of the AVR backend to
> not send any emails to the general public, but to instead send emails to
> the buildbot owner and maintainer of the AVR backend.
>
> Agree with this
>
> +1. The silent staging buildbot is what you want I believe
> http://lists.llvm.org/pipermail/lldb-commits/Week-
> of-Mon-20151012/024214.html
>
> That sounds good. My plan is to make the buildbot a staging bot, and then
> be the sole receiver of emails from it.
>
> If I was in this position, I’d also configure the bot to build *only* the
> AVR backend. That’s help make sure that an email does get send when a test
> fails in the X86 backend.
>
> I would love to do this, but there’s a bug in the backend which causes a
> few of the Generic CodeGen tests to fail. To work around this, I leave X86
> as the default target for now. I’m definitely planning on updating this
> once I’ve fixed the bug.
>
>
> This usually happens when LLVM_DEFAULT_TARGET_TRIPLE is not explicitely
> set and you end up with your host machine as default while not building the
> x86 target. If you set LLVM_DEFAULT_TARGET_TRIPLE to some AVR ones the
> failure should go away (otherwise complain and file bugs).
>
>
> Actually I believe you have to set it to empty to disable “generic” tests.
>
>
> Confirmed:
>
> $ cat llvm/test/CodeGen/Generic/lit.local.cfg
> if not config.target_triple:
>     config.unsupported = True
>
>
> —
> Mehdi
>
>
>
> _______________________________________________
> 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/20170204/cb134dcc/attachment.html>