Don't use reexecution as the means to implement trigger-after

The scheme was based on the notion that memory accesses are idempotent
up until the point the trigger would've been hit, which isn't true in
the case of side-effecting loads and data-value triggers.

Instead, check the trigger on the next instruction fetch.  To keep the
perf overhead minimal, perform this check on the I$ refill path, and
ensure that path is taken by flushing the I$.

1 files changed, 0 insertions, 9 deletions

diff --git a/riscv/execute.cc b/riscv/execute.cc
index 5d24ce8..f0bb946 100644
--- a/riscv/execute.cc
+++ b/riscv/execute.cc
@@ -309,15 +309,6 @@ void processor_t::step(size_t n)
     catch (triggers::matched_t& t)
     {
       if (mmu->matched_trigger) {
-        // This exception came from the MMU. That means the instruction hasn't
-        // fully executed yet. We start it again, but this time it won't throw
-        // an exception because matched_trigger is already set. (All memory
-        // instructions are idempotent so restarting is safe.)
-
-        insn_fetch_t fetch = mmu->load_insn(pc);
-        pc = execute_insn(this, pc, fetch);
-        advance_pc();
-
         delete mmu->matched_trigger;
         mmu->matched_trigger = NULL;
       }