On Sun, Jan 7, 2018 at 3:36 PM, Jeff Law <l...@redhat.com> wrote: > On 01/07/2018 03:58 PM, H.J. Lu wrote: >> This set of patches for GCC 8 mitigates variant #2 of the speculative >> execution >> vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre. >> They >> convert indirect branches to call and return thunks to avoid speculative >> execution >> via indirect call and jmp. >> >> >> H.J. Lu (5): >> x86: Add -mindirect-branch= >> x86: Add -mindirect-branch-loop= >> x86: Add -mfunction-return= >> x86: Add -mindirect-branch-register >> x86: Add 'V' register operand modifier >> >> gcc/config/i386/constraints.md | 12 +- >> gcc/config/i386/i386-opts.h | 14 + >> gcc/config/i386/i386-protos.h | 2 + >> gcc/config/i386/i386.c | 655 >> ++++++++++++++++++++- >> gcc/config/i386/i386.h | 10 + >> gcc/config/i386/i386.md | 51 +- >> gcc/config/i386/i386.opt | 45 ++ >> gcc/config/i386/predicates.md | 21 +- >> gcc/doc/extend.texi | 22 + >> gcc/doc/invoke.texi | 37 +- > My fundamental problem with this patchkit is that it is 100% x86/x86_64 > specific. > > ISTM we want a target independent mechanism (ie, new standard patterns, > options, etc) then an x86/x86_64 implementation using that target > independent framework (ie, the actual implementation of those new > standard patterns). >
My patch set is implemented with some constraints: 1. They need to be backportable to GCC 7/6/5/4.x. 2. They should work with all compiler optimizations. 3. They need to generate code sequences are x86 specific, which can't be changed in any shape or form. And the generated codes are quite opposite to what a good optimizing compiler should generate. Given that these conditions, I kept existing indirect call, jump and return patterns. I generated different code sequences for these patterns during the final pass when generating assembly codes. I guess that I could add a late target independent RTL pass to convert indirect call, jump and return patterns to something else. But I am not sure if that is what you are looking for. -- H.J.
