On Fri, Jan 12, 2018 at 10:41 PM, Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Jan 12, 2018 at 10:29:01PM +0100, Arnd Bergmann wrote: >> On Fri, Jan 12, 2018 at 9:41 PM, Segher Boessenkool >> <segher@xxxxxxxxxxxxxxxxxxx> wrote: >> > On Fri, Jan 12, 2018 at 08:43:21PM +0100, Arnd Bergmann wrote: >> >> On Fri, Jan 12, 2018 at 5:39 PM, Segher Boessenkool >> >> >> We could theoretically work around it by turning that into >> >> "#if defined(CONFIG_CC_OPTIMIZE_FOR_SIZE) || >> >> defined(CONFIG_CRYPTO_AES)", but that seems rather ugly. >> >> >> >> My earlier patch already tried to be more specific, turning very >> >> specific optimizations off rather than moving from -O2 to -Os, >> >> but that turned out to lead to significantly worse performance, >> >> where -Os improved performance slightly. Is there a way >> >> to ask powerpc compilers to use mostly -Os but not the >> >> specific thing that makes it link to _restgpr_31_x? >> > >> > There is no such thing, sorry. Would be very hard to implement, and >> > older compilers will never get it, so it won't help you anyway :-( >> >> We use -Os only for gcc-7.1 and higher, where it produces faster >> code for AES and avoids running into >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356 >> >> > Maybe for now just enable it in crtsavres.S always, with a comment? >> > That -Os workaround is hopefully not going to live long either... >> >> It depends on whether or how soon someone comes up with a >> better fix for PR83356. >> gcc-8.0.0 is currently not affected by it, so we could limit the >> workaround (and the hack in crtsavres.S) to gcc-7-only. > > I guess you could enable the _x routines whenever you use ubsan? Ubsan > will cause much bigger code growth than the handful of insns in those > routines? Right, that could work, too. My patch that Herbert merged intentionally used -Os also for non-UBSAN builds because it turned out to be much faster (see gcc PR83651), but we could revert that back to the default and only use the -Os for UBSAN, essentially addressing only PR83356 but not PR83651. Arnd
