This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Reduce stack usage in sha512 (PR target/77308)
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Eric Botcazou <ebotcazou at adacore dot com>, Richard Biener <richard dot guenther at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Nick Clifton <nickc at redhat dot com>, Richard Earnshaw <richard dot earnshaw at arm dot com>, "Ramana Radhakrishnan" <ramana dot radhakrishnan at arm dot com>
- Date: Fri, 30 Sep 2016 10:14:23 +0000
- Subject: Re: [PATCH] Reduce stack usage in sha512 (PR target/77308)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=softfail (sender IP is 10.152.12.52) smtp.mailfrom=hotmail.de; gcc.gnu.org; dkim=none (message not signed) header.d=none;gcc.gnu.org; dmarc=none action=none header.from=hotmail.de;
- References: <AM4PR0701MB21629E281C1C4538834D9806E4C10@AM4PR0701MB2162.eurprd07.prod.outlook.com> <CAFiYyc3hqNF5oZR1PfYboW=EjruEu3+LiWw10246PoRKjhqHVg@mail.gmail.com>,<5106795.3uCmH4qeSv@polaris>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Eric Botcazou wrote:
>> A comment before the SETs and a testcase would be nice. IIRC
>> we do have stack size testcases via using -fstack-usage.
>
>Or -Wstack-usage, which might be more appropriate here.
Yes. good idea. I was not aware that we already have that kind of tests.
When trying to write this test. I noticed, that I did not try -Os so far.
But for -Os the stack is still the unchanged 3500 bytes.
However for embedded targets I am often inclined to use -Os, and
would certainly not expect the stack to explode...
I see in arm.md there are places like
/* If we're optimizing for size, we prefer the libgcc calls. */
if (optimize_function_for_size_p (cfun))
FAIL;
/* Expand operation using core-registers.
'FAIL' would achieve the same thing, but this is a bit smarter. */
scratch1 = gen_reg_rtx (SImode);
scratch2 = gen_reg_rtx (SImode);
arm_emit_coreregs_64bit_shift (LSHIFTRT, operands[0], operands[1],
operands[2], scratch1, scratch2);
.. that explains why this happens. I think it would be better to
use the emit_coreregs for shift count >= 32, because these are
effectively 32-bit shifts.
Will try if that can be improved, and come back with the
results.
Thanks
Bernd.