Branch prediction counter

[pdonahue-ventana]

Is it OK to have a branch prediction counter (the internal counter value that eventually gets output in the format 0 branch_count field) that's less than 32 bits (e.g. to make it possible to hit the maximum value in simulation without simulating billions of branches)? The branch_count field itself would be 32 bits but I just mean that the internal counter is smaller so that the upper bits in the packet cannot be 1.

My inclination is that the answer is yes. If your implementation has a maximum value of N then you'd output a packet with count=N after every N+31 correctly predicted branches and then upon a mispredict, you'd output a final packet with the last few branches. This is just like what happens when N=2³²-1.

For instance, if N=1023 and you have 5000 correctly predicted branches, you'd output four packets with count=1023 and then a packet with count=753 (which is 5000-4*(1023+31)-31). Or it doesn't even seem like N needs to be a power of two minus 1 so if N=1234 and you have 5000 correctly predicted branches, you'd output three packets with count=1234 and then a packet with count=1174 (which is 5000-3*(1234+31)-31).

[IainCRobertson]

Paul, Actually it's not as simple as that, and you can't just shorten the counter without taking some other mitigating action. Here's why: Normally when an address is reported (either using format 1 or with a format 0 branch count), it is because there has been an uninferrable jump. The decoder follows the execution path until it has processed all the branches, and then stops when it encounters the reported address. However, it's possible that it might encounter this address inferrably, and this has to be taken care of. See section 7.6.2 of the E-trace spec, and also the 'inferred_address' Boolean in the decoder pseudo-code. When the format 0 branch count message is output because it has reached the maximum value, the decoder needs to use the fact that count value is the max in order to know that the address isn't being reported because it's an updiscon target (i.e. inferred_address must remain FALSE). A branch predictor message at the max value of a smaller count will not be treated like this, and the result is that upon receipt of the next message the decoder will continue on the execution path looking for the address from the previous packet. In order to ensure the decoder works correctly with a smaller counter, you would have to set the notify bit in the packet (even though there is no notify trigger). The description of the notify bit is that it "indicates that this packet is reporting an instruction that is not the target of an uninferrable discontinuity because a notification was requested". I'd argue that the part in green is really informative only - the part in blue is the important (normative) part. The decoder doesn't care why the address isn't an updiscon target. The alternative is to use a force in simulation to inject a large value into the counter. This is what we did. I'd be open to adding a clarification to the spec for this though. What do you think? Iain From: Paul Donahue ***@***.***> Sent: 10 April 2025 23:12 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Subscribed ***@***.***> Subject: [riscv-non-isa/riscv-trace-spec] Branch prediction counter (Issue #224) Is it OK to have a branch prediction counter (the internal counter value that eventually gets output in the format 0 branch_count field) that's less than 32 bits (e.g. to make it possible to hit the maximum value in simulation without simulating billions of branches)? The branch_count field itself would be 32 bits but I just mean that the internal counter is smaller so that the upper bits in the packet cannot be 1. My inclination is that the answer is yes. If your implementation has a maximum value of N then you'd output a packet with count=N after every N+31 correctly predicted branches and then upon a mispredict, you'd output a final packet with the last few branches. This is just like what happens when N=232-1. For instance, if N=1023 and you have 5000 correctly predicted branches, you'd output four packets with count=1023 and then a packet with count=753 (which is 5000-4*(1023+31)-31). Or it doesn't even seem like N needs to be a power of two minus 1 so if N=1234 and you have 5000 correctly predicted branches, you'd output three packets with count=1234 and then a packet with count=1174 (which is 5000-3*(1234+31)-31). - Reply to this email directly, view it on GitHub<#224>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSRK3ASNITHZ3IPH45D2Y3UCRAVCNFSM6AAAAAB24YH3AOVHI2DSMVQWIX3LMV43ASLTON2WKOZSHE4DOMBSGI2DINQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>> [https://avatars.githubusercontent.com/u/48959409?s=20&v=4]pdonahue-ventana created an issue (riscv-non-isa/riscv-trace-spec#224)<#224> Is it OK to have a branch prediction counter (the internal counter value that eventually gets output in the format 0 branch_count field) that's less than 32 bits (e.g. to make it possible to hit the maximum value in simulation without simulating billions of branches)? The branch_count field itself would be 32 bits but I just mean that the internal counter is smaller so that the upper bits in the packet cannot be 1. My inclination is that the answer is yes. If your implementation has a maximum value of N then you'd output a packet with count=N after every N+31 correctly predicted branches and then upon a mispredict, you'd output a final packet with the last few branches. This is just like what happens when N=232-1. For instance, if N=1023 and you have 5000 correctly predicted branches, you'd output four packets with count=1023 and then a packet with count=753 (which is 5000-4*(1023+31)-31). Or it doesn't even seem like N needs to be a power of two minus 1 so if N=1234 and you have 5000 correctly predicted branches, you'd output three packets with count=1234 and then a packet with count=1174 (which is 5000-3*(1234+31)-31). - Reply to this email directly, view it on GitHub<#224>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSRK3ASNITHZ3IPH45D2Y3UCRAVCNFSM6AAAAAB24YH3AOVHI2DSMVQWIX3LMV43ASLTON2WKOZSHE4DOMBSGI2DINQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[pdonahue-ventana]

The spec doesn't imply that there's any leeway on the size of this counter but readers might think that there's a shortcut. I think that it's worth a sentence to help steer people away from that.

[IainCRobertson]

Agreed - how does this look? #227