> -----Original Message-----
> From: Richard Henderson <richard.hender...@linaro.org>
> Sent: Thursday, October 8, 2020 2:02 PM
> To: Taylor Simpson <tsimp...@quicinc.com>; qemu-devel@nongnu.org
> Cc: phi...@redhat.com; laur...@vivier.eu; riku.voi...@iki.fi;
> aleksandar.m.m...@gmail.com; a...@rev.ng
> Subject: Re: [RFC PATCH v3 26/34] Hexagon (target/hexagon) macros
> referenced in instruction semantics
>
> On 10/8/20 1:51 PM, Taylor Simpson wrote:
> >> How can it have done without doing the merging by hand. Which this
> operation ordering is intended to make unnecessary.
> >>
> >> I think you're missing the point.
> >
> > Sorry I wasn't clear. We have done the load from memory as it was at the
> beginning of the packet. The result of the store is in mem_log_stores in
> CPUHexagonState. This code updates the bytes that were loaded with any
> overlapping bytes from the store that hasn't been committed yet.
>
> Right, so you *are* missing the point.
>
> The point is to *not* do the load earlier, but only probe the memory for
> readability so that any exception is recognized before the store commits.
>
> Then, after the store, actually perform the load. Thus any overlapping bytes
> get the values that they should.
That's what I coded originally, but after sleeping on it decided it could lead
to problems. See below...
> Voila, no by-hand merging.
>
> > 67f8: c0 40 21 1f 1f2140c0 { v0.uh = vsat(v0.uw,v1.uw)
> > 67fc: 00 45 02 a1 a1024500 memb(r2+#0) = r5
> > 6800: 02 c0 04 91 9104c002 r2 = memb(r4+#0) }
> >
> > The vsat instruction requires a vector context. If the thread doesn't have
> > a
> vector context, an exception will be raised. The OS can provide a context and
> replay the packet.
>
> Sure.
>
> Is there any per-packet exception priority that would require a fault from the
> store to be provided in preference to the fault for the vector context?
I don't think there's a priority for the exceptions. In this example, any of
the 3 instructions could generate an exception. The thing I'm worried about
isn't that the store could generate an exception. The problem is letting the
store change the machine state before we're sure none of the instructions will
raise an exception. Maybe I'm worrying about something that would never result
in different behavior - if the packet gets replayed, we'll just store the same
value again.
I'll reach out to the architects and ask if there is a case where doing the
store first could be a problem - and also about the priority of exceptions.
> Anyway, I'm suggesting ordering the operations within the packet to be one
> that's most convenient for us.
This may or may not be possible. We already have to reorder to put .new
consumers after the producers, and we have to keep the change-of-flow
instructions in the original order. So, I'm reluctant to go down this path
worrying that there will be a long tail of corner case bugs to engineer out.
