[PATCH] D15393: [X86] Order the local stack symbols to improve code size and locality.
Sean Silva via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 9 17:29:55 PST 2016
On Tue, Feb 9, 2016 at 7:25 AM, Sanjay Patel <spatel at rotateright.com> wrote:
> spatel added a subscriber: spatel.
> spatel added a comment.
>
> In http://reviews.llvm.org/D15393#347116, @silvas wrote:
>
> > One interesting thing to also note: the 11, 9, and 12 rows have such
> bloated instruction sizes primarily because of needing to store an
> immediate "0" as an imm32. (we have some open PR's about this I think).
>
>
> Excellent data visualization - thanks! If you have a chance, it would be
> interesting to recompile the app that you're looking at with this patch
> applied to see if that app benefits.
>
My findings are in this PDF of my Mathematica notebook:
https://drive.google.com/file/d/0B8v10qJ6EXRxVVc1NVpMNk1UV0k/view?usp=sharing
The summary w.r.t. text size is that there is about a 1% text size
improvement.
Also, there is a measurable performance improvement on the level that I was
testing on (sorry, I didn't do a more in-depth test across multiple levels).
The 99'th percentile frame time is improved by a whopping 1.6%! The median
and 90'th percentile only improve about half a percent, but that is still a
very respectable improvement for general-purpose backend tuning!
Note: this was for a regular O3 build, not a peak performance build
(LTO+PGO). However, this is likely to be more important during LTO since
there is generally greater inlining and so greater pressure on stack
frames. Sorry, didn't have enough time to measure all the {configurations}
x {levels} like when I'm doing an in-depth analysis!
-- Sean Silva
>
> The related instruction-size bugzillas that I filed are:
> https://llvm.org/bugs/show_bug.cgi?id=24447
> https://llvm.org/bugs/show_bug.cgi?id=24448
> https://llvm.org/bugs/show_bug.cgi?id=24449
>
> We made some progress on the example in the last report, but that may not
> apply to the cases that you were looking at. It's possible that this helps
> too:
> http://reviews.llvm.org/rL256969
>
>
> http://reviews.llvm.org/D15393
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160209/17377174/attachment.html>
More information about the llvm-commits
mailing list