[PATCH] Emit lifetime start/end for unnamed objects --- take 3

[Arnaud A. de Grandmaison]

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: cfe-commits-bounces at cs.uiuc.edu [mailto:cfe-commits-bounces at cs.uiuc.edu] 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:chandlerc at google.com] 
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 <arnaud.degrandmaison at arm.com> 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

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140926/feb8c6bf/attachment.html>