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. > 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
