It's really just modeling a simplified dispatcher, which stalls conservatively unless it knows it can dispatch the next instruction regardless of its type. We've made some changes internally at AMD to relax this, and will try to post them before too long. It's not terribly hard to change on your own.
Steve On Mon, Mar 4, 2013 at 9:48 AM, Mitch Hayenga <[email protected]>wrote: > 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
