Hi Chandler,
So I have built llvm+clang+lldb which a clang with various thresholds, and here are the results (user time in seconds for a build from scratch, averaged over 5 builds). Note that the reported threshold is inclusive: 33 (the current threshold) means all object whose size >= 33 bytes will be marked for example. Threshold Average Variance 33 4652.67 4.51 32 4677.02 2.71 16 4681.50 11.06 8 4660.23 12.47 0 4667.47 8.63 There are some minor fluctuation that I cannot really explain, but we just have no compromise to make there: always insert the lifetime markers J When I will remove the threshold, I will send a heads-up as there may be code out there triggering interesting compile time behaviour / optimization passes not playing well with the lifetime markers (there have been some commits in that area recently). Cheers, -- Arnaud From: [email protected] [mailto:[email protected]] On Behalf Of Arnaud A. de Grandmaison Sent: 25 September 2014 11:51 To: 'Chandler Carruth' Cc: llvm cfe Subject: RE: [PATCH] Emit lifetime start/end for unnamed objects --- take 3 From: Chandler Carruth [mailto:[email protected]] Sent: 25 September 2014 11:23 To: Arnaud De Grandmaison Cc: David Blaikie; llvm cfe Subject: Re: [PATCH] Emit lifetime start/end for unnamed objects --- take 3 On Tue, Sep 16, 2014 at 1:29 AM, Arnaud A. de Grandmaison <[email protected]> wrote: I do not know how this 32 bytes threshold has been choosen, but there is for sure a compile time / stack size gain trade-off to be made. Really? I can't understand why we want *any* threshold here. I think we should aggressively mark all temporaries with this and fix the algorithms to deal with compile time. I will then bootstrap llvm+clang as a testcase, with various thresholds and no threshold so that we know if we have compile time issues or not. We can then decide of the proper follow-up: remove the threshold, or lower it to an acceptable value until some passes get fixed. My experiments have shown that for our customer case, the threshold should be lower: 16-bytes. But changing this threshold would require a separate thread on this list, as well as much more measurements. The improvements I have been able to get, by visual inspection of the generated assembly code, for a single call of the hot functions were: | GCC | Clang | LT-32 | LT-16 | ===+=====+=======+=======+=======+ F1 | 432 | 608 | 608 | 400 | F2 | 432 | 640 | 640 | 432 | F3 | 384 | 368 | 368 | 192 | F4 | 320 | 400 | 400 | 224 | Stack size is expressed in bytes. GCC version 4.8 LT-32 is clang with this patch (default 32 bytes threshold for all temporaries). LT-16 is clang with this patch and a 16 bytes threshold for all temporaries. This is, quite simply, amazing. Please push this. Feel free to CC me if you get stuck, this is crazy important to get fixed. Thanks Chandler ! Arnaud
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
