> On Aug. 19, 2014, 5:11 p.m., Nilay Vaish wrote: > > src/cpu/o3/inst_queue_impl.hh, line 1116 > > <http://reviews.gem5.org/r/2332/diff/1/?file=40491#file40491line1116> > > > > We should use nullptr now that we have gcc minimum dependency at 4.6. > > Mitch Hayenga wrote: > Hmm, at one point in this patch or another I had to try to return nullptr > and someone took issue with it I believe. Either way, personally I don't > care. > > Grepping our code base (this might be different from the mainline gem5) > it seems we only use nullptr eleven times in the code base and only in > network-related code. Should a later "consistency" patch try to change this? > Because currently it looks like NULL is the preferred. > > $ grep -r NULL * | wc -l > 1515 > $ grep -r nullptr * | wc -l > 11
We can have a single patch or we can do it in a lazy fashion. I am fine with either. Any new code that goes in should use nullptr. The incident you mention probably happened before we moved to GCC 4.6 being the minimum required version. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2332/#review5272 ----------------------------------------------------------- On Aug. 13, 2014, 2:06 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2332/ > ----------------------------------------------------------- > > (Updated Aug. 13, 2014, 2:06 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10300:bddebc19285f > --------------------------- > cpu: Fix cached block load behavior in o3 cpu > > This patch fixes the load blocked/replay mechanism in the o3 cpu. Rather than > flushing the entire pipeline, this patch replays loads once the cache becomes > unblocked. > > Additionally, deferred memory instructions (loads which had conflicting > stores), > when replayed would not respect the number of functional units (only respected > issue width). This patch also corrects that. > > Improvements over 20% have been observed on a microbenchmark designed to > exercise this behavior. > > > Diffs > ----- > > src/cpu/o3/iew.hh 79fde1c67ed8 > src/cpu/o3/iew_impl.hh 79fde1c67ed8 > src/cpu/o3/inst_queue.hh 79fde1c67ed8 > src/cpu/o3/inst_queue_impl.hh 79fde1c67ed8 > src/cpu/o3/lsq.hh 79fde1c67ed8 > src/cpu/o3/lsq_impl.hh 79fde1c67ed8 > src/cpu/o3/lsq_unit.hh 79fde1c67ed8 > src/cpu/o3/lsq_unit_impl.hh 79fde1c67ed8 > src/cpu/o3/mem_dep_unit.hh 79fde1c67ed8 > src/cpu/o3/mem_dep_unit_impl.hh 79fde1c67ed8 > > Diff: http://reviews.gem5.org/r/2332/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
