> On July 20, 2013, 9:49 a.m., Andreas Hansson wrote: > > src/cpu/o3/lsq.hh, line 322 > > <http://reviews.gem5.org/r/1958/diff/1/?file=36753#file36753line322> > > > > My bad, std::vector<LSQUnit> is what I was thinking
Ah, I see. I just tried this, and there are issues with the stats allocators that cause failed linking. In particular, when instantiating multiple LSQUnits into this vector in the initialization list of the LSQ constructor, g++ instantiates a single LSQUnit and then calls the LSQUnit copy constructor to create the rest in the vector. These calls to the LSQUnit copy constructor call the DataWrap copy constructor for each of the stats. This fails because the stats DataWrap copy constructor is a stub intended to fail linking if it is called (see src/base/statistics.hh:231) - presumably to keep devs from dynamically allocating stats within a SimObject or within an STL container that might copy them. I've played around with the DataWrap copy constructor just to get things to build and run, and we still run into the bug that this patch is intended to fix, namely, there are LSQUnits that are allocated but their stats are not initialized. It appears this is because the standard STL vector allocator is allowed to allocate more objects than are necessarily used to allow for easily increasing the size of the vector without reallocating space. I think we'd need to write a custom allocator in order to use std::vector<LSQUnit>. - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1958/#review4540 ----------------------------------------------------------- On July 19, 2013, 5:35 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1958/ > ----------------------------------------------------------- > > (Updated July 19, 2013, 5:35 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 9818:132e2bbe723e > --------------------------- > cpu: Dynamically instantiate O3 CPU LSQUnits > > Previously, the LSQ would instantiate MaxThreads LSQUnits in the body of it's > object, but it would only initialize numThreads LSQUnits as specified by the > user. This had the effect of leaving some LSQUnits uninitialized when the > number of threads was less than MaxThreads, and when adding statistics to the > LSQUnit that must be initialized, this caused the stats initialization check > to > fail. By dynamically instantiating LSQUnits, they are all initialized and this > avoids uninitialized LSQUnits from floating around during runtime. > > > Diffs > ----- > > src/cpu/o3/lsq.hh 971507cbbe65 > src/cpu/o3/lsq_impl.hh 971507cbbe65 > src/cpu/o3/lsq_unit_impl.hh 971507cbbe65 > > Diff: http://reviews.gem5.org/r/1958/diff/ > > > Testing > ------- > > Ran O3 regressions and tested checkpoint restore with additional LSQUnit > stats. > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
