I agree with Segher. We already know we have opportunities to do a better
job with shrink-wrapping (pushing this kind of useless activity down past
early exits), so having examples of code to look at to improve this would
be useful.
-- Bill
Bill Schmidt, Ph.D.
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@us.ibm.com (507) 319-6873
From: Segher Boessenkool <seg...@kernel.crashing.org>
To: Anton Blanchard <an...@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org, Michael
Gschwind/Watson/IBM@IBMUS, Alan Modra <amo...@gmail.com>, Bill
Schmidt/Rochester/IBM@IBMUS, Ulrich Weigand
<ulrich.weig...@de.ibm.com>, pau...@samba.org
Date: 08/05/2015 06:20 AM
Subject: Re: RFC: Reducing the number of non volatile GPRs in the ppc64
kernel
Hi Anton,
On Wed, Aug 05, 2015 at 02:03:00PM +1000, Anton Blanchard wrote:
> While looking at traces of kernel workloads, I noticed places where gcc
> used a large number of non volatiles. Some of these functions
> did very little work, and we spent most of our time saving the
> non volatiles to the stack and reading them back.
That is something that should be fixed in GCC -- do you have an example
of such a function?
> It made me wonder if we have the right ratio of volatile to non
> volatile GPRs. Since the kernel is completely self contained, we could
> potentially change that ratio.
>
> Attached is a quick hack to gcc and the kernel to decrease the number
> of non volatile GPRs to 8. I'm not sure if this is a good idea (and if
> the volatile to non volatile ratio is right), but this gives us
> something to play with.
Instead of the GCC hack you can add a bunch of -fcall-used-r14 etc.
options; does that not work for you?
Segher
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
