On Sat, Jan 27, 2018 at 09:18:32AM +0000, Ard Biesheuvel wrote: > As reported by kbuild test robot, the optimized SHA3 C implementation > compiles to mn10300 code that uses a disproportionate amount of stack > space, i.e., > > crypto/sha3_generic.c: In function 'keccakf': > crypto/sha3_generic.c:147:1: warning: the frame size of 1232 bytes is > larger than 1024 bytes [-Wframe-larger-than=] > > As kindly diagnosed by Arnd, this does not only occur when building for > the mn10300 architecture (which is what the report was about) but also > for h8300, and builds for other 32-bit architectures show an increase in > stack space utilization as well. > > Given that SHA3 operates on 64-bit quantities, and keeps a state matrix > of 25 64-bit words, it is not surprising that 32-bit architectures with > few general purpose registers are impacted the most by this, and it is > therefore reasonable to implement a workaround that distinguishes between > 32-bit and 64-bit architectures. > > Arnd figured out that taking the round calculation out of the loop, and > inlining it explicitly but only on 64-bit architectures preserves most > of the performance gain achieved by the rewrite, and also gets rid of > the excessive use of stack space. > > Reported-by: kbuild test robot <fengguang...@intel.com> > Suggested-by: Arnd Bergmann <a...@arndb.de> > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt