Hi guys, It looks as though the O3 CPU load-store queue automatically instantiates 4 (MaxThreads) LSQUnits during the header of it's constructor. This appears to be problematic when trying to use statistics that need to be initialized in the LSQUnit, because these stats cannot be initialized if the number of SMT threads being used is fewer than MaxThreads. The stats initialization check in src/base/statistics.cc:~220 will fail on these uninitialized LSQUnit stats.
It seems to me that as long as the number of SMT threads specified by the user in config scripts is not greater than MaxThreads, these LSQUnits should be instantiated dynamically by the LSQ in it's constructor, so that there aren't unused objects floating around in the simulation. This would fix the stats initialization bug I'm running into. Is there any reason why the LSQUnits aren't being dynamically instantiated (e.g. dynamically changing SMT width during runtime)? Thanks, Joel -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
