When performing analysis to locate LLC misses, the miss count is attributed to the correct source code statement, but when opening the Assembly statement, the count is attributed to the first assembly code statement for the source code statement and not to the correct assembly statement. For a simple fetch of data this is not much of a problem, however in a convoluted expression with multiple array references, it does not help much to figure out which reference caused the LLC miss.
This is known as "event skid" (see documentation). Using "precise" events can help, but it is unavoidable. This is where the "human touch" comes into the equation. Your analysis of what the instructions are doing can help determine where the miss is occurring.
This is not a case of "event skid". The particular situation was an expression whereby the memory read of the statement followed (if I recall correctly) about 6 assembly statements (of that source statement) that were register to register. The count was attributed to the 1st assembly statement of the 15 or so that constituted the source statement.. In the normal "event skid" situation the event is attributed after the initiator of the event. In this case, the attribution came before the initiation of the event. I will see if I can supply a screenshot next time.
This phenomenon can occur in a loop: when the event is triggered by an instruction near the end of the loop. By the time the processor is able to capture the instruction pointer, it is has jumped to the top of the loop.
Is your case in a loop?
I will have to re-run the test (made edits and code no longer in same locations). I seem to recall that this was in-line code. When (if) I get a screen shot it will confirm what the situation is/is not with respect to loop. This is a case of whether the code took the blue pill or the red pill.