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

Arnaud A. de Grandmaison arnaud.degrandmaison at arm.com
Thu Sep 25 02:51:00 PDT 2014


 

 

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/20140925/3470c796/attachment.html>


More information about the cfe-commits mailing list