This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/5] x86: Add -mindirect-branch-loop=
- From: David Woodhouse <dwmw2 at infradead dot org>
- To: "Kumar, Venkataramanan" <Venkataramanan dot Kumar at amd dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Jeff Law <law at redhat dot com>, Paul Turner <pjt at google dot com>, "asit dot k dot mallick at intel dot com" <asit dot k dot mallick at intel dot com>
- Cc: "Nagarajan, Muthu kumar raj" <Muthukumarraj dot Nagarajan at amd dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot cz>, "Uros Bizjak (ubizjak at gmail dot com)" <ubizjak at gmail dot com>, Jan Hubicka <jh at suse dot de>, "Dharmakan, Rohit arul raj" <Rohitarulraj dot Dharmakan at amd dot com>
- Date: Sat, 13 Jan 2018 08:58:28 +0000
- Subject: Re: [PATCH 2/5] x86: Add -mindirect-branch-loop=
- Authentication-results: sourceware.org; auth=none
- References: <20180107225904.11535-1-hjl.tools@gmail.com> <20180107225904.11535-3-hjl.tools@gmail.com> <7194fc49-e057-b5f6-fd4d-e21803bba26c@redhat.com> <ri61siv1cbz.fsf@suse.cz> <CAMe9rOrCwj6gQG9pYEXwgvf9wOWufox5k+5OT_LybOb97KpGhg@mail.gmail.com> <CY4PR12MB17367B4AAAC8B1C47480BCA88F170@CY4PR12MB1736.namprd12.prod.outlook.com> <CY4PR12MB17369FEEF1805F6FEA2748078F170@CY4PR12MB1736.namprd12.prod.outlook.com> <CY4PR12MB17361DEA1EAC1B074E9CAA1C8F170@CY4PR12MB1736.namprd12.prod.outlook.com> <CAMe9rOprj71VuM7KNbbgwmh7Dn+G5YErz0z8C6iOxCFQxB=vmA@mail.gmail.com> <CY4PR12MB1736E9749DB0EA87A4CC6F618F140@CY4PR12MB1736.namprd12.prod.outlook.com>
On Sat, 2018-01-13 at 03:11 +0000, Kumar, Venkataramanan wrote:
>
> > My original patch uses "lfence". I was asked to use "pause":
> >
> > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00969.html
>
> If everyone is ok, my suggestion is to use "lfence" as the default
> loop filler for retpoline.
>
> Please confirm.
I have had the same request for the kernel patches. I'm happy with it
but would like confirmation from Intel and from Paul Turner (whose idea
this is, and who has overseen most of the coherent analysis).
FWIW I haven't actually *changed* the kernel patch yet, awaiting that
confirmation. I understand this is a power optimisation only;
preventing the CPU from spinning in that loop when it's mispredicted a
return to it.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature