LSQ: Only trigger a memory violation with a load/load if the value changes.

Only create a memory ordering violation when the value could have changed
between two subsequent loads, instead of just when loads go out-of-order
to the same address. While not very common in the case of Alpha, with
an architecture with a hardware table walker this can happen reasonably
frequently beacuse a translation will miss and start a table walk and
before the CPU re-schedules the faulting instruction another one will
pass it to the same address (or cache block depending on the dendency
checking).

This patch has been tested with a couple of self-checking hand crafted
programs to stress ordering between two cores.

The performance improvement on SPEC benchmarks can be substantial (2-10%).

1 files changed, 13 insertions, 0 deletions

diff --git a/src/cpu/base_dyn_inst.hh b/src/cpu/base_dyn_inst.hh
index 5f0a6106e..5719fc84d 100644
--- a/src/cpu/base_dyn_inst.hh
+++ b/src/cpu/base_dyn_inst.hh
@@ -146,6 +146,19 @@ class BaseDynInst : public FastAlloc, public RefCounted
     /** True if the DTB address translation has completed. */
     bool translationCompleted;
 
+    /** True if this address was found to match a previous load and they issued
+     * out of order. If that happend, then it's only a problem if an incoming
+     * snoop invalidate modifies the line, in which case we need to squash.
+     * If nothing modified the line the order doesn't matter.
+     */
+    bool possibleLoadViolation;
+
+    /** True if the address hit a external snoop while sitting in the LSQ.
+     * If this is true and a older instruction sees it, this instruction must
+     * reexecute
+     */
+    bool hitExternalSnoop;
+
     /**
      * Returns true if the DTB address translation is being delayed due to a hw
      * page table walk.