From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [cryptodev:master 130/134] aes_generic.c:undefined reference to `_restgpr_31_x' Date: Fri, 12 Jan 2018 22:45:31 +0100 Message-ID: References: <201801122249.RHvvGQJ6%fengguang.wu@intel.com> <20180112163946.GE21977@gate.crashing.org> <20180112204154.GM21977@gate.crashing.org> <20180112214111.GQ21977@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , kbuild test robot , linuxppc-dev , Herbert Xu To: Segher Boessenkool Return-path: Received: from mail-oi0-f45.google.com ([209.85.218.45]:33476 "EHLO mail-oi0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965253AbeALVpc (ORCPT ); Fri, 12 Jan 2018 16:45:32 -0500 Received: by mail-oi0-f45.google.com with SMTP id y141so4872750oia.0 for ; Fri, 12 Jan 2018 13:45:32 -0800 (PST) In-Reply-To: <20180112214111.GQ21977@gate.crashing.org> Sender: linux-crypto-owner@vger.kernel.org List-ID: On Fri, Jan 12, 2018 at 10:41 PM, Segher Boessenkool 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 >> 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