This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Changes in mode switching
- From: Vladimir Yakovlev <vbyakovl23 at gmail dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Vladimir Makarov <vmakarov at redhat dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>
- Date: Tue, 2 Oct 2012 14:08:31 +0400
- Subject: Re: [PATCH] Changes in mode switching
- References: <CAFULd4bvo40rOhNHm7c5puor-9mKCVVnj_WO0NVgkxYuoq-sLw@mail.gmail.com> <CAK1BsWrRaRcq9GRvsQn=hbOf5+qpo-xG9gVb1Nmdee=0cvGE2w@mail.gmail.com> <CAFULd4b9Xnobdk9sjepSzfih=W8mZTV4V8OEiS+iAG2qQNk9-g@mail.gmail.com> <CAK1BsWpqvmDfaEpuUfXJ8rx2__c2n_5LaJuEsKASfChPoCiujQ@mail.gmail.com> <CAFULd4bKvzSZ5QdJwPSpREjT+nvsCRQH84fEzJmXAdAd2AWK=g@mail.gmail.com> <CAK1BsWpH1iZ+N4FCLkMT0zyNiomj8nYG3RqqNgNarHrpWzCNUA@mail.gmail.com> <CAFULd4YBdEA1+OLAfMVAXFuiMZL-i9ad3ROaWsHhU_pQt+PkTw@mail.gmail.com> <CAFULd4ZjezSjvY4NC8RJ6aGt-8sDtz56DfHyk9Rg8Vf5CM7+ig@mail.gmail.com> <CAK1BsWoOnLDxiL1rrzcLmi67Sa7==oNS6VHs+9r1tbSR6KK7FQ@mail.gmail.com> <CAFULd4aRsx-J1f3esRcYK97zSh-8uS4JBkfsuk3aDtwFXw4=TA@mail.gmail.com>
Will we wait for LRA commit or is it possiple to commit to trank
vzeroupper patch now?
2012/10/2 Uros Bizjak <ubizjak@gmail.com>:
> On Tue, Oct 2, 2012 at 11:35 AM, Vladimir Yakovlev <vbyakovl23@gmail.com> wrote:
>>>>> The compiler with the patch and without post_reload.patch is built and works
>>>>> successfully. It has the only failure with avx-vzeroupper-3 test because of
>>>>> post reload problem.
>>>>
>>>> Ok, can you please elaborate a bit on this filure? Perhaps someone has
>>>> an idea why reload moves unspec_volatile around?
>>>
>>> LRA will eventually replace reload in the nearby future [1], does LRA
>>> also move unspec_volatile vzeroupper around?
>>>
>>> [1] http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01862.html
>>
>> I tried my patch with LRA. It works fine. The test avx-vzeroupper-3
>> runs succesfully, unspec_volatile vzeroupper is not moved around in
>> LRA.
>
> Great!
>
> This also means +1 to include LRA in 4.8 from x86 maintainer. We also
> expect spill falure fixes and other improvements for pre-reload
> scheduling from LRA.
>
> Uros.