This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PING] [PATCH, ARM] 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: Thu, 6 Oct 2016 16:19:00 +0000
- Subject: [PING] [PATCH, ARM] 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; adacore.com; dkim=none (message not signed) header.d=none;adacore.com; dmarc=none action=none header.from=hotmail.de;
- References: <AM4PR0701MB21629E281C1C4538834D9806E4C10@AM4PR0701MB2162.eurprd07.prod.outlook.com> <CAFiYyc3hqNF5oZR1PfYboW=EjruEu3+LiWw10246PoRKjhqHVg@mail.gmail.com> <5106795.3uCmH4qeSv@polaris> <AM4PR0701MB21623769225A738C608614F2E4C10@AM4PR0701MB2162.eurprd07.prod.outlook.com> <AM4PR0701MB21623B90CEF983BD09E688C2E4C10@AM4PR0701MB2162.eurprd07.prod.outlook.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Hi,
I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02362.html
Thanks,
Bernd.
On 09/30/16 15:33, Bernd Edlinger wrote:
> On 09/30/16 12:14, Bernd Edlinger wrote:
>> 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;
>>
>
> Oh, yeah. The comment is completely misleading.
>
> If this pattern fails, expmed.c simply expands some
> less efficient rtl, which also results in two shifts
> and one or-op. No libgcc calls at all.
>
> So in simple cases without spilling the resulting
> assembler is the same, regardless if this pattern
> fails or not. But the half-defined out registers
> make a big difference when it has to be spilled.
>
>> /* 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.
>>
>
> The test case with -Os has 3520 bytes stack usage.
> When only shift count >= 32 are handled we
> have still 3000 bytes stack usage.
> And when arm_emit_coreregs_64bit_shift is always
> allowed to run, we have 2360 bytes stack usage.
>
> Also for the code size it is better not to fail this
> pattern. So I propose to remove this exception in all
> three expansions.
>
> Here is an improved patch with the test case from the PR.
> And a comment on the redundant SET why it is better to clear
> the out register first.
>
>
> Bootstrap and reg-testing on arm-linux-gnueabihf.
> Is it OK for trunk?
>
>
> Thanks
> Bernd.