> On July 19, 2013, 5:39 p.m., Andreas Hansson wrote: > > src/cpu/o3/lsq_impl.hh, line 114 > > <http://reviews.gem5.org/r/1958/diff/1/?file=36754#file36754line114> > > > > If it's a vector, then you can do this in the initalisation list and > > the delete goes away.
> On July 19, 2013, 5:39 p.m., Andreas Hansson wrote: > > src/cpu/o3/lsq.hh, line 322 > > <http://reviews.gem5.org/r/1958/diff/1/?file=36753#file36753line322> > > > > Could this perhaps be a std::vector<LSQUnit*> rather? Sure, though we'd still need to dynamically allocate the LSQUnits in the LSQ constructor loop, and change all of the "thread[tid]." to dereference the appropriate LSQUnits unless we use pointer references. This would also fail to eliminate the LSQ destructor unless we explicitly templatize the vector to call the LSQUnit destructor. If we dynamically allocate, we'll need to call a destructor somewhere. The vector route seems pretty messy unless I'm missing something you're saying here? - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1958/#review4537 ----------------------------------------------------------- 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
