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

Chandler Carruth chandlerc at google.com
Thu Sep 25 02:22:49 PDT 2014


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.


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140925/9ac110e4/attachment.html>


More information about the cfe-commits mailing list