This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: reload autoinc fix
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Jeff Law <law at redhat dot com>, Bernd Schmidt <bernds at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, John David Anglin <danglin at gcc dot gnu dot org>
- Date: Wed, 08 Jan 2014 10:36:24 +0000
- Subject: Re: reload autoinc fix
- Authentication-results: sourceware.org; auth=none
- References: <52CC287B dot 6000102 at codesourcery dot com> <52CC69BD dot 7000009 at redhat dot com> <CA+=Sn1m_-Y_uqVbYH0+JSpymy-y3uvtA+=iKMF60KAfgQQHRJw at mail dot gmail dot com>
On 07/01/14 21:06, Andrew Pinski wrote:
> On Tue, Jan 7, 2014 at 12:55 PM, Jeff Law <law@redhat.com> wrote:
>> On 01/07/14 09:16, Bernd Schmidt wrote:
>>>
>>> This is PR56791. The address inside of an autoinc is reloaded, and the
>>> autoinc is reloaded, but the reload insns are emitted in the wrong order.
>>>
>>> As far as I can tell, this is because find_reloads_address_1 has two
>>> methods of pushing a reload for an autoinc, one of them using the
>>> previously identified type, and the other (better one) using
>>> RELOAD_OTHER. If we previously reloaded an inner part of the address,
>>> the use of RELOAD_OTHER is mismatched and leads to the wrong order of
>>> insns.
>>>
>>> This patch just remembers if we've pushed a reload, and forces the
>>> optimization to be skipped in that case. Bootstrapped and tested on
>>> x86_64-linux (with lra_p disabled but still somewhat pointlessly); John
>>> Anglin said in the PR that it tests ok on PA. Will commit in a few days
>>> if no objections.
>>
>> No objections to the substance of the patch, though I think the comment
>> could be clearer.
>
> Though my question is what target does this matter since ARM has moved
> away from reload and other targets should do the same?
>
There's still the chance we will have to move back for this release when
building Thumb1. Only if we can iron out enough of the bugs/size
regressions will we stick with LRA for that permutation.
R.