[llvm] r285296 - [DAGCombiner] Add vector demanded elements support to computeKnownBits

[Juergen Ributzka via llvm-commits]

The build slaves are not necessarily homogeneous, so you have to choose a conservative value that fits all. I didn’t set the limit, but I recall it was set high on purpose to avoid false positives. We don’t want to bug developers with unnecessary email.

I don’t think a lower limit would be a great utility to find compile time regressions either and it isn’t the purpose of this bot. LNT has way better support to identify and track compile time regressions.

Cheers,
Juergen


> On Oct 27, 2016, at 3:49 PM, Davide Italiano <davide at freebsd.org> wrote:
> 
> On Thu, Oct 27, 2016 at 3:48 PM, Davide Italiano <davide at freebsd.org <mailto:davide at freebsd.org>> wrote:
>> On Thu, Oct 27, 2016 at 3:36 PM, Juergen Ributzka via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>>> Hi Simon,
>>> 
>>> I think this commit is causing timeouts on our LTO builds on green dragon:
>>> http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto/10676/
>>> 
>>> A build usually takes 45min and we kill them if they last more than 90min.
>>> 
>> 
>> Out of curiosity, why is the timeout so high? I understand that false
>> positives are not great, but 2x seems a little bit excessive.
>> Have you already tried with 1.5x (or something around that value)?
>> 
>> P.S. Ideally we {sh,c}ould have a decent infrastructure for tracking
>> compile-time regressions (at least this is what I'm more concerned
>> about because of LTO, others might care about runtime performance as
>> well), but this is not a hill I want to die on (at least not today),
>> and I still think lowering the timeout threshold could help finding
>> regressions.
>> 
> 
> To clarify, I'm only talking about bots doing LTO, not the whole fleet.
> 
> -- 
> Davide
> 
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161027/0e2608de/attachment.html>