This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC PATCH, i386]: Enable post-reload compare elimination pass
- From: Jeff Law <law at redhat dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>, Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, Nick Clifton <nickc at redhat dot com>, Eric Botcazou <ebotcazou at adacore dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Thu, 22 Jun 2017 22:46:26 -0600
- Subject: Re: [RFC PATCH, i386]: Enable post-reload compare elimination pass
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com ED4117AE99
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com ED4117AE99
- References: <CAFULd4beOEsXre1y+nz5c0iOUMVDmLYLO9yUiizHCtYw9bOWmg@mail.gmail.com> <20170510142710.GY1809@tucnak> <CAFULd4be1V1BkuzZx4+7i6ouwPqeFXWWo6QMkCXqqwh6GbedzQ@mail.gmail.com> <CAFULd4ZLes9A0mFFYvnv-CDC+n9w7hFw67PsP7Q9UTwz2eGUVA@mail.gmail.com> <CAFULd4Zku7jTKtwY_oSyAesrhcpOiSvfCEVx7=DxNX-L7f+ZoA@mail.gmail.com> <20170510202708.GI1809@tucnak> <alpine.BSF.2.02.1705111659530.69598@arjuna.pair.com> <da33bd16-7f37-cbf7-1a6a-c16b1c2630fb@redhat.com> <alpine.BSF.2.02.1705162219520.51815@arjuna.pair.com> <CAFULd4aEXGkCY6rOueY9U+JNcQTX5JMHP3gOBEmUY2iOWiu_bw@mail.gmail.com>
On 05/17/2017 12:33 AM, Uros Bizjak wrote:
> On Wed, May 17, 2017 at 4:45 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
>
>>> But yes, we definitely should document the final canonical ordering.
>>
>> Is that about to also happen?
>>
>> I foresee in another half-a-dozen years, and *this* iteration is
>> forgotten, someone bothered enough to argue eloquently coming
>> around, doing rtl-level-maintenance, maybe a new pass (ok maybe
>> not a *new RTL-pass* :) sees that order as wrong for the reason
>> listed above, and does the legwork to switch the order around.
>> It will be ok to change it again then, because the order just
>> happened this time because of minimal-edit-reasons, right?
>> Noone can argue that it was a thoughtful deliberate change that
>> we bothered to document, to stay consistent? ;)
>
> The proposed doc patch is wiating for review at [1].
>
> [1] https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01073.html
OK for the trunk.
Sorry for the delay,
jeff