diff mbox series

[target/86811] Mark VAX as not needing speculation barriers

Message ID 20190917205913.GC3418@SDF.ORG
State New
Headers show
Series [target/86811] Mark VAX as not needing speculation barriers | expand

Commit Message

Maya Rashish Sept. 17, 2019, 8:59 p.m. UTC
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.

---
 gcc/config/vax/vax.c | 3 +++
 1 file changed, 3 insertions(+)

--

Comments

Jeff Law Sept. 20, 2019, 8:22 p.m. UTC | #1
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
Maciej W. Rozycki Oct. 3, 2019, 2:12 a.m. UTC | #2
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
Jeff Law Oct. 3, 2019, 2:29 a.m. UTC | #3
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
Segher Boessenkool Oct. 3, 2019, 10:34 a.m. UTC | #4
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
Maciej W. Rozycki Oct. 3, 2019, 11:16 a.m. UTC | #5
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
Segher Boessenkool Oct. 3, 2019, 11:40 a.m. UTC | #6
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 mbox series

Patch

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.  */