It looks like the logic is just organized poorly. Yes, it will unnecessarily stall non-loads if there are no free LSQ entries. It shouldn't take many changes to fix this (basically changing the later while loop to track number of LSQ entries remaining and accounting based upon number of loads sent to IEW).
On Sun, Mar 3, 2013 at 8:33 PM, shruti padmanabha <[email protected]>wrote: > Hi, > > In the O3 model, dispatch to the IQ is blocked when the LSQ is full, even > for non-memRef instructions. > > Relevant snippets of code from rename_impl.hh: > > In renameInsts(ThreadID tid): > > if (free_lsq_entries < min_free_entries) { > min_free_entries = free_lsq_entries; > source = LSQ; > } > > if (min_free_entries < insts_available) { > DPRINTF(Rename, "[tid:%u]: Will have to block this cycle." > "%i insts available, but only %i insts can be " > "renamed due to ROB/IQ/LSQ limits.\n", > tid, insts_available, min_free_entries); > } > > Could you tell me why this check is implemented? I would expect non memory > instructions in O3 to go along to execute even if the LSQ has no free > entries. > > Thanks, > Shruti > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
