> 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 > > Joel Hestness wrote: > 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>.
Wow, thanks for all the digging. I forgot about the vector behaviour. Keep it simple then :-) - Andreas ----------------------------------------------------------- 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
