This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2] S/390: Allow LARL of literal pool entries
- From: Ilya Leoshkevich <iii at linux dot ibm dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, krebbel at linux dot ibm dot com, rdapp at linux dot ibm dot com
- Date: Mon, 5 Nov 2018 11:03:51 +0100
- Subject: Re: [PATCH v2] S/390: Allow LARL of literal pool entries
- References: <20181031095952.68331D803B8@oc3748833570.ibm.com>
> Am 31.10.2018 um 10:59 schrieb Ulrich Weigand <uweigand@de.ibm.com>:
>
> Ilya Leoshkevich wrote:
>> Am 30.10.2018 um 18:22 schrieb Ulrich Weigand <uweigand@de.ibm.com>:
>>> This definitely looks wrong. If we haven't annotated the address,
>>> it should *not* be found by find_constant_pool_ref, since we are
>>> not going to replace it! That was the whole point of not annotating
>>> it in the first place ...
>>
>> There are two use cases for find_constant_pool_ref (). One is indeed
>> replacing annotated references. The other (in s390_mainpool_start ()
>> and s390_chunkify_start ()) is creating pool entries. So I've decided
>> to let it find unannotated references for the second use case.
>
> OK, but if we access the constant via relative address, we don't need
> to copy it into the back-end managed pool either; the relative address
> can just refer the constant in the default pool maintained by the
> middle end.
Wouldn’t that prevent constant merging in case the same constant is
used with both relative and base-register addressing?