[llvm-dev] Benchmark LNT weird thread behaviour

[Renato Golin via llvm-dev]

Right, so the bots now pass threads directly, so the worst part is over.

Now, being the same thing, I wonder if we just deprecate -j and emit an
error, or a warning of which got chosen, or silently prefer - - threads
over - j if both are emitted. I don't think the current behaviour of - j
silently overriding - - threads is a good model, though.

Cheers,
Renato

On 21 Sep 2016 8:57 p.m., "Chris Matthews" <chris.matthews at apple.com> wrote:

-j and —threads are the same flag. The problem is passing it twice with two
different values.  I am sort of surprised OptionParser let that past.


On September 21, 2016 at 2:33:48 AM, Renato Golin via llvm-dev (
llvm-dev at lists.llvm.org) wrote:

On 21 September 2016 at 01:33, Chris Matthews <chris.matthews at apple.com>
wrote:
> I think every job should define those or use the LNT default of 1,1. The
> validity of compile time and exec time metrics is in question if the job
is
> loaded incorrectly, so it makes sense to me to not allow that -j to get
> passed through.

The job's default *is* -j1. But we pass -jN to the other steps
(compiling Clang, for instance).

We also pass -jN to LNT, because that means both build and execute in one
go.

I'll change the buildbots to pass both explicitly in nt_flags, and
will also change the builder to not pass -j in any case.

But if users should not be passing -jN, but instead --threads and
--build-threads directly, than I think we should make it into an error
in LNT, no?

cheers,
--renato
_______________________________________________
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/20160922/54c878ae/attachment.html>