Clearly specify FENCE.I ordering requirements (riscv#2167)

* Clearly specify FENCE.I ordering requirements

The ratified FENCE.I definition specifies a sufficient code sequence
for multiprocessor instruction-memory modification (on the producer,
store to instruction memory, fence, then communicate with the consumer;
on the consumer, observe communication, fence.i, then execute the new code).

However, the spec does not explain _why_ this sequence suffices.  The
explanation is that FENCE.I orders older loads on the same thread before
younger instruction fetches.  (Otherwise, nothing would force the consumer's
observation of the communication to occur before the next fetch.)

Combined with the existing statement in the spec that older stores on the
same hart are ordered before younger fetches, the overall implied rule
is easy to state: FENCE.I orders all older explicit memory accesses before
all younger fetches.

* Change register allocation for clarity

Author: aswaterman

src/zifencei.adoc

@@ -78,6 +78,35 @@ instruction memory visible to all RISC-V harts, the writing hart also
 has to execute a data FENCE before requesting that all remote RISC-V
 harts execute a FENCE.I.
 
+A FENCE.I instruction orders all explicit memory accesses that precede the
+FENCE.I in program order before all instruction fetches that follow the
+FENCE.I in program order.
+
+[NOTE]
+====
+In the following litmus test, for example, the outcome `a0`=1, `a1`=0 on
+the consumer hart is forbidden, assuming little-endian RV32IC harts:
+
+```
+Initially, flag = 0.
+
+Producer hart:                                  Consumer hart:
+
+la t0, patch_me                                 la t2, flag
+li t1, 0x4585                                   lw a0, (t2)
+sh t1, (t0)   # patch_me := c.li a1, 1          fence.i
+fence w, w    # order flag write              patch_me:
+la t0, flag                                     c.li a1, 0
+li t1, 1
+sw t1, (t0)   # flag := 1
+```
+
+Note that this example is only meant to illustrate the aforementioned ordering
+property.
+In a realistic producer-consumer code-generation scheme, the consumer would loop
+until `flag` becomes 1 before executing the FENCE.I instruction.
+====
+
 The unused fields in the FENCE.I instruction, _funct12_, _rs1_, and
 _rd_, are reserved for finer-grain fences in future extensions. For
 forward compatibility, base implementations shall ignore these fields,