Message ID | 20190917205913.GC3418@SDF.ORG |
---|---|
State | New |
Headers | show |
Series | [target/86811] Mark VAX as not needing speculation barriers | expand |
On 9/17/19 2:59 PM, coypu@sdf.org wrote: > According to Bob Supnik (who is a very authoritative source on VAX), > >> Funny you should ask. The short answer is no. No VAX ever did >> speculative or out of order execution. > > As such, marking VAX as not needing speculation barriers. > > > PR target/86811 > * config/vax/vax.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): > Define to speculation_safe_value_not_needed. Installed on the trunk. jeff
On Fri, 20 Sep 2019, Jeff Law wrote: > > According to Bob Supnik (who is a very authoritative source on VAX), > > > >> Funny you should ask. The short answer is no. No VAX ever did > >> speculative or out of order execution. > > > > As such, marking VAX as not needing speculation barriers. > > > > > > PR target/86811 > > * config/vax/vax.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): > > Define to speculation_safe_value_not_needed. > Installed on the trunk. I don't think this is right. As I have just mentioned in a related discussion elsewhere, the NVAX and NVAX+ implementations include a branch predictor in their microarchitecture[1], so obviously they do execute speculatively. I think this change would best be reverted and the issue further investigated. References: [1] G. Michael Uhler et al, "The NVAX and NVAX+ High-performance VAX Microprocessors", Digital Technical Journal Vol. 4 No. 3 Summer 1992 <ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ701/DTJ701PF.PDF> Maciej
On 10/2/19 8:12 PM, Maciej W. Rozycki wrote: > On Fri, 20 Sep 2019, Jeff Law wrote: > >>> According to Bob Supnik (who is a very authoritative source on VAX), >>> >>>> Funny you should ask. The short answer is no. No VAX ever did >>>> speculative or out of order execution. >>> >>> As such, marking VAX as not needing speculation barriers. >>> >>> >>> PR target/86811 >>> * config/vax/vax.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): >>> Define to speculation_safe_value_not_needed. >> Installed on the trunk. > > I don't think this is right. As I have just mentioned in a related > discussion elsewhere, the NVAX and NVAX+ implementations include a branch > predictor in their microarchitecture[1], so obviously they do execute > speculatively. I think this change would best be reverted and the issue > further investigated. Simply having branch prediction and simple speculation onto one side of the branch isn't sufficient. Otherwise a whole lot more processors would, in theory, be vulnerable. IIRC you also need some degree of out of order execution, or at least the ability to keep speculating past memory accesses and high enough quality timers to distinguish between a cache hit and cache miss. All this seems fairly academic for the vax. jeff
On Thu, Oct 03, 2019 at 03:12:34AM +0100, Maciej W. Rozycki wrote: > On Fri, 20 Sep 2019, Jeff Law wrote: > > > > According to Bob Supnik (who is a very authoritative source on VAX), > > > > > >> Funny you should ask. The short answer is no. No VAX ever did > > >> speculative or out of order execution. > > > > > > As such, marking VAX as not needing speculation barriers. > > > > > > > > > PR target/86811 > > > * config/vax/vax.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): > > > Define to speculation_safe_value_not_needed. > > Installed on the trunk. > > I don't think this is right. As I have just mentioned in a related > discussion elsewhere, the NVAX and NVAX+ implementations include a branch > predictor in their microarchitecture[1], so obviously they do execute > speculatively. I think this change would best be reverted and the issue > further investigated. > > References: > > [1] G. Michael Uhler et al, "The NVAX and NVAX+ High-performance VAX > Microprocessors", Digital Technical Journal Vol. 4 No. 3 Summer 1992 > <ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ701/DTJ701PF.PDF> As that article explains, the NVAX does *not* execute speculatively. You can have branch prediction without speculative execution just fine. It is beneficial, too, because this hides the fetch latency when a branch is predicted correctly. When a (conditional) branch executes, it is detected if the branch was mispredicted, and if so it (and everything after it) is flushed. This is similar to how it was done on the PowerPC 6xx CPUs, or on the original Pentium, etc. Segher
On Thu, 3 Oct 2019, Segher Boessenkool wrote: > > I don't think this is right. As I have just mentioned in a related > > discussion elsewhere, the NVAX and NVAX+ implementations include a branch > > predictor in their microarchitecture[1], so obviously they do execute > > speculatively. I think this change would best be reverted and the issue > > further investigated. > > > > References: > > > > [1] G. Michael Uhler et al, "The NVAX and NVAX+ High-performance VAX > > Microprocessors", Digital Technical Journal Vol. 4 No. 3 Summer 1992 > > <ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ701/DTJ701PF.PDF> > > As that article explains, the NVAX does *not* execute speculatively. You > can have branch prediction without speculative execution just fine. It > is beneficial, too, because this hides the fetch latency when a branch is > predicted correctly. > > When a (conditional) branch executes, it is detected if the branch was > mispredicted, and if so it (and everything after it) is flushed. This is > similar to how it was done on the PowerPC 6xx CPUs, or on the original > Pentium, etc. OK, I stand corrected. For the sake of my enlightenment, do you specifically refer to this statement: "If the I-box predicts incorrectly, the E-box invokes a trap mechanism to drain the pipeline and restart the I-box at the alternate PC." (page 5, section "The I-box") or something else? Maciej
On Thu, Oct 03, 2019 at 12:16:46PM +0100, Maciej W. Rozycki wrote: > On Thu, 3 Oct 2019, Segher Boessenkool wrote: > > When a (conditional) branch executes, it is detected if the branch was > > mispredicted, and if so it (and everything after it) is flushed. This is > > similar to how it was done on the PowerPC 6xx CPUs, or on the original > > Pentium, etc. > > OK, I stand corrected. For the sake of my enlightenment, do you > specifically refer to this statement: > > "If the I-box predicts incorrectly, the E-box invokes a trap mechanism to > drain the pipeline and restart the I-box at the alternate PC." > > (page 5, section "The I-box") or something else? Yes, that is it. Segher
diff --git a/gcc/config/vax/vax.c b/gcc/config/vax/vax.c index 1c220ff..fe5f04e 100644 --- a/gcc/config/vax/vax.c +++ b/gcc/config/vax/vax.c @@ -121,6 +121,9 @@ static HOST_WIDE_INT vax_starting_frame_offset (void); #undef TARGET_STARTING_FRAME_OFFSET #define TARGET_STARTING_FRAME_OFFSET vax_starting_frame_offset +#undef TARGET_HAVE_SPECULATION_SAFE_VALUE +#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed + struct gcc_target targetm = TARGET_INITIALIZER; /* Set global variables as needed for the options enabled. */