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