Patch forthcoming.
Created attachment 216043 [details] the patch
Comment on attachment 216043 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=216043&action=review > Tools/ChangeLog:11 > + memory leaps and attaching a profiler. You probably meant "memory leaks"
Comment on attachment 216043 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=216043&action=review > Tools/ReducedFTL/ReducedFTL.c:66 > + printf("--fast-isel Enable the \"fast\" instruction selector.\n"); Does --fast-isel work anymore? The new LLVM intrinsics don't support --fast-isel, and nobody seems to be working on supporting it right now.
(In reply to comment #3) > (From update of attachment 216043 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=216043&action=review > > > Tools/ReducedFTL/ReducedFTL.c:66 > > + printf("--fast-isel Enable the \"fast\" instruction selector.\n"); > > Does --fast-isel work anymore? The new LLVM intrinsics don't support --fast-isel, and nobody seems to be working on supporting it right now. It depends on what you mean by "working". Enable fast isel means that, on a per-basic-block basis, the instruction selector will attempt fast isel. If it encounters an instruction that it cannot handle, it will silently fall back to the selection dag. Our basic blocks are fairly small and most of them don't have a call to any of our intrinsics. Hence enabling fast isel is a valid thing to consider. Current experiments show that it's not a good idea (20% compile time savings but a 30% throughput reduction) but that does't mean we can't sometimes try it.
(In reply to comment #2) > (From update of attachment 216043 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=216043&action=review > > > Tools/ChangeLog:11 > > + memory leaps and attaching a profiler. > > You probably meant "memory leaks" But memory leaps are so much cooler!
Landed in http://trac.webkit.org/changeset/158679