Why are we insisting on doing something on the bots that takes ~10x longer to 
run than necessary? I’d rather have that time spent running more tests.

Overall, how we’re doing things now feels like a bad allocation of bot 
resources. The differences I see between O3 with no-inlining vs O0 is:
- Some race conditions will behave differently. Race conditions are already non 
predictable. I don’t think we’re losing anything here.
- O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t in O0, 
and vice versa. In general, we probably care more about O3 compiler bugs than 
O0, since we don’t ship O0, but ship a lot of O3.

(And if we’re going to insist on “I want it to run what I build at my desk”: I 
run debug with O3 at my desk, and I can run debug tests in a reasonable amount 
of time now.)

In evaluating what’s the better setup, I think it’s helpful to think about this 
from the other side. Let’s imagine we had Debug+O3 as our current setup. And 
someone proposed to move it to O0 and make our tests take ~10x longer. I think 
that’d be a non-starter.

- Saam

> On Jun 17, 2020, at 9:48 PM, Simon Fraser <simon.fra...@apple.com> wrote:
> 
> I also object to losing good stack traces for crashes on Debug bots.
> 
> Also, I don't think Debug bots should build something different from what I 
> build at my desk.
> 
> Simon
> 
>> On Jun 17, 2020, at 1:36 PM, Mark Lam <mark....@apple.com> wrote:
>> 
>> Hi folks,
>> 
>> We're planning to switch the JSC EWS bot and build.webkit.org Debug build 
>> and test bots to building with the following set first:
>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>> 
>> This means the Debug builds will be built with optimization level forced to 
>> O3.
>> 
>> Why are we doing this?
>> 1. So that the JSC EWS will start catching ASSERT failures.
>> 2. JSC stress test Debug bots have been timing out and not running tests at 
>> all.  Hopefully, this change will fix this issue.
>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>> 
>> The downside: crash stack traces will be like Release build stack traces.  
>> But I don’t think we should let this deter us.  It’s not like there’s no 
>> stack information.  And just as we do with debugging Release build test 
>> failures, we can always do a Debug build locally to do our debugging.
>> 
>> We would like to apply this change to all Debug build and test bots, not 
>> just the JSC ones.  Does anyone strongly object to this change?
>> 
>> Thanks.
>> 
>> Cheers,
>> Mark
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to