Hello all, I’ve been staring at the memory trace of a benchmark and am confused as to why some loads that I expect to commit are not being committed. Note that I am using Ruby.
I’ve been tracing the path loads take and it seems to be the following (More information can be found here https://www.gem5.org/project/2020/07/18/gem5-o3cpu-backend.html): instToCommit primarily seems to just add the instruction to a structure called an “iewQueue”, but nothing is actually committed. Then later on, in the tick() function in iew_impl.hh, the load is actually committed using the following code: // Update structures based on instructions committed. if (fromCommit->commitInfo[tid].doneSeqNum != 0 && !fromCommit->commitInfo[tid].squash && !fromCommit->commitInfo[tid].robSquashing) { ldstQueue.commitStores(fromCommit->commitInfo[tid].doneSeqNum,tid); ldstQueue.commitLoads(fromCommit->commitInfo[tid].doneSeqNum,tid); updateLSQNextCycle = true; instQueue.commit(fromCommit->commitInfo[tid].doneSeqNum,tid); } In the commitLoads function [see code excerpt above], the load entry is actually freed from the LSQ. I’ve been trying to find the link between the “instToCommit” function and the code in “tick” but to no avail. Where/how exactly does the tick function decide if it can commit a load? Essentially, what’s the bridge between IEW:instToCommit and IEW::tick? I was trying to figure out the connection between “fromCommit” [see code excerpt above] and “iewQueue", but it seems to involve wires, time buffers and several other concepts I’m not familiar with. Thanks, Farhad
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
