They only do to use CCallHelpers::Jump or CCallHelpers::Label. But CCallHelpers inherit those from MacroAssembler. And MacroAssembler.h is dramatically cheaper to include (since CCallHelpers includes AssemblyHelpers which includes CodeBlock.h which includes roughly the entire runtime).
Created attachment 389204 [details] Patch
Comment on attachment 389204 [details] Patch My patch visibly does not apply cleanly on ToT.
Created attachment 389210 [details] Patch
Created attachment 389213 [details] Patch
Created attachment 389214 [details] Patch
Created attachment 389616 [details] Patch Fix style nits.
Comment on attachment 389616 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=389616&action=review > Source/JavaScriptCore/b3/B3Common.cpp:42 > - return FTL::verboseCompilationEnabled() || FTL::shouldDumpDisassembly() || shouldDumpIRAtEachPhase(mode); > + return DFG::verboseCompilationEnabled(DFG::FTLMode) || DFG::shouldDumpDisassembly(DFG::FTLMode) || shouldDumpIRAtEachPhase(mode); I don't think this is a good thing to do. There's no guarantee that FTL::verboseCompilationEnabled() will always be a forwarding wrapper to DFG::verboseCompilationEnabled(). Ditto for FTL::shouldDumpDisassembly(). I suggest either: 1. Get rid of FTL::verboseCompilationEnabled() and FTL::shouldDumpDisassembly(), and use DFG versions everywhere. Or ... 2. Create a separate header file that contains FTL::verboseCompilationEnabled() and FTL::shouldDumpDisassembly() only, and continue to use them here. Or ... 3. Continue to #include "FTLState.h" here. I recommend either (2) or (3). > Source/WTF/wtf/SingleRootGraph.h:32 > +#include <wtf/StringPrintStream.h> Isn't this already in the code base? I see it in my local checkout. If so, make sure to remove the ChangeLog as well.
Created attachment 390023 [details] Patch - I verified that even without unified sources this patch does not break the build - I reverted the change that removed FTLState.h from B3Common, following Mark's comment - I removed the wtf/Changelog since the corresponding change has already landed in the tree
Comment on attachment 390023 [details] Patch r=me. If you have a record of the build time difference on a unified build of JSC, it would be nice to include that as well in the ChangeLog for posterity.
(In reply to Mark Lam from comment #9) > Comment on attachment 390023 [details] > Patch > > r=me. If you have a record of the build time difference on a unified build > of JSC, it would be nice to include that as well in the ChangeLog for > posterity. Thanks for the review. The compile time of JSC as a whole is a bit too variable to give good results here. But from what I remember, the difference when looking only at B3 files was quite significant (something like 20% in Debug builds).
Comment on attachment 390023 [details] Patch Clearing flags on attachment: 390023 Committed r256003: <https://trac.webkit.org/changeset/256003>
All reviewed patches have been landed. Closing bug.
<rdar://problem/59248505>