This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] xtensa: add -mauto-litpools option
- From: Max Filippov <jcmvbkbc at gmail dot com>
- To: "augustine dot sterling at gmail dot com" <augustine dot sterling at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 12 Aug 2015 20:47:18 +0300
- Subject: Re: [PATCH] xtensa: add -mauto-litpools option
- Authentication-results: sourceware.org; auth=none
- References: <1439341740-1912-1-git-send-email-jcmvbkbc at gmail dot com> <CAGSvup_+1WaLnL6VoNcC95-Lv91ri6__+TcgQWKoZQy1Z5gpAA at mail dot gmail dot com>
On Wed, Aug 12, 2015 at 7:35 PM, augustine.sterling@gmail.com
<augustine.sterling@gmail.com> wrote:
> On Tue, Aug 11, 2015 at 6:09 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> With support from assembler this option allows compiling huge functions,
>> where single literal pool at the beginning of a function may not be
>> reachable by L32R instructions at its end.
>>
>> Currently assembler --auto-litpools option cannot deal with literals
>> used from multiple locations separated by more than 256 KBytes of code.
>> Don't turn constants into literals, instead use MOVI instruction to load
>> them into registers and let the assembler turn them into literals as
>> necessary.
>
> If this is OK with the linux people, it is OK with me. As I recall,
> they used to have a need to keep literals in page-level groups, but my
> memory is hazy.
Text-section-literals remain available, and without auto-litpools option
code generation doesn't change at all. Even with auto-litpools option
literals will tend to pool at the beginning of functions, so code generation
shouldn't change much.
I've applied the patch to trunk.
--
Thanks.
-- Max