On 01/12/2018 07:05 AM, H.J. Lu wrote:
> On Fri, Jan 12, 2018 at 4:38 AM, Martin Jambor <mjam...@suse.cz> wrote:
>> Hi,
>>
>> On Thu, Jan 11 2018, Jeff Law wrote:
>>> On 01/07/2018 03:59 PM, H.J. Lu wrote:
>>>> Add -mindirect-branch-loop= option to control loop filler in call and
>>>> return thunks generated by -mindirect-branch=.  'lfence' uses "lfence"
>>>> as loop filler.  'pause' uses "pause" as loop filler.  'nop' uses "nop"
>>>> as loop filler.  The default is 'lfence'.
>>>>
>>>> gcc/
>>>>
>>>>      * config/i386/i386-opts.h (indirect_branch_loop): New.
>>>>      * config/i386/i386.c (output_indirect_thunk): Support
>>>>      -mindirect-branch-loop=.
>>>>      * config/i386/i386.opt (mindirect-branch-loop=): New option.
>>>>      (indirect_branch_loop): New.
>>>>      (lfence): Likewise.
>>>>      (pause): Likewise.
>>>>      (nop): Likewise.
>>>>      * doc/invoke.texi: Document -mindirect-branch-loop= option.
>>>>
>>>> gcc/testsuite/
>>>>
>>>>      * gcc.target/i386/indirect-thunk-loop-1.c: New test.
>>>>      * gcc.target/i386/indirect-thunk-loop-2.c: Likewise.
>>>>      * gcc.target/i386/indirect-thunk-loop-3.c: Likewise.
>>>>      * gcc.target/i386/indirect-thunk-loop-4.c: Likewise.
>>>>      * gcc.target/i386/indirect-thunk-loop-5.c: Likewise.
>>> I think we should drop the ability to change the filler until such time
>>> as we really need it.  Just pick one and go with it.  I think David
>>> suggested that they wanted "pause".  I'm obviously fine with that.
>>>
>>
>> unless I am mistaken (which is frankly quite possible, I am still not
>> quite up to speed about the nuances), AMD strongly prefers the lfence
>> variant.  OTOH, IIUC, in kernel this will be run-time patched but so it
>> does not matter in the most pressing case and we might want to have a
>> mechanism doing something similar for protecting userspace later on.
>> But perhaps it is enough to keep the option?
>>
>> Muthu and/or Venkat, can you please comment?
> 
> If we do want it, I will submit a separate patch AFTER the current patch
> set has been approved and checked into GCC 8.
That would be my preference, if we need it at all.

jeff

Reply via email to