----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3027/#review7656 -----------------------------------------------------------
src/cpu/o3/probe/elastic_trace.cc (lines 72 - 75) <http://reviews.gem5.org/r/3027/#comment6598> I think these checks are needless. Two reasons. First, since the python params do not have default values, the user would be forced to provide some value. Second, even if the user were to provide an empty value, the ProtoOutputStream constructor should fail. src/cpu/o3/probe/elastic_trace.cc (lines 104 - 113) <http://reviews.gem5.org/r/3027/#comment6599> IIRC, we have talked about this before. I think there is no need for the "if {} " at all. src/cpu/o3/probe/elastic_trace.cc (line 333) <http://reviews.gem5.org/r/3027/#comment6601> Get this pointer from itr_temp_store. src/cpu/o3/probe/elastic_trace.cc (lines 426 - 432) <http://reviews.gem5.org/r/3027/#comment6602> Since you need the mapped value later, follow the pattern you have been following in other parts of the code: call find and get the iterator first. src/cpu/o3/probe/elastic_trace.cc (lines 682 - 687) <http://reviews.gem5.org/r/3027/#comment6603> Is this correct? Should not comp_delay = completionTick - executionTick . Secondly, the assert should be comparing the unsigned values as we discussed in another thread. src/cpu/o3/probe/elastic_trace.cc (lines 724 - 728) <http://reviews.gem5.org/r/3027/#comment6604> Same problems as above. src/cpu/o3/probe/elastic_trace.cc (line 857) <http://reviews.gem5.org/r/3027/#comment6605> Is the post decrement of any use? - Nilay Vaish On Nov. 19, 2015, 5:18 p.m., Curtis Dunham wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3027/ > ----------------------------------------------------------- > > (Updated Nov. 19, 2015, 5:18 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > The elastic trace is a type of probe listener and listens to probe points > in multiple stages of the O3CPU. The notify method is called on a probe > point typically when an instruction successfully progresses through that > stage. > > As different listener methods mapped to the different probe points execute, > relevant information about the instruction, e.g. timestamps and register > accesses, are captured and stored in temporary InstExecInfo class objects. > When the instruction progresses through the commit stage, the timing and the > dependency information about the instruction is finalised and encapsulated in > a struct called TraceInfo. TraceInfo objects are collected in a list instead > of writing them out to the trace file one a time. This is required as the > trace is processed in chunks to evaluate order dependencies and computational > delay in case an instruction does not have any register dependencies. By this > we achieve a simpler algorithm during replay because every record in the > trace can be hooked onto a record in its past. The instruction dependency > trace is written out as a protobuf format file. A second trace containing > fetch requests at absolute timestamps is written to a separate protobuf > format file. > > If the instruction is not executed then it is not added to the trace. > The code checks if the instruction had a fault, if it predicated > false and thus previous register values were restored or if it was a > load/store that did not have a request (e.g. when the size of the > request is zero). In all these cases the instruction is set as > executed by the Execute stage and is picked up by the commit probe > listener. But a request is not issued and registers are not written. > So practically, skipping these should not hurt the dependency modelling. > > If squashing results in squashing younger instructions, it may happen that > the squash probe discards the inst and removes it from the temporary > store but execute stage deals with the instruction in the next cycle which > results in the execute probe seeing this inst as 'new' inst. A sequence > number of the last processed trace record is used to trap these cases and > not add to the temporary store. > > The elastic instruction trace and fetch request trace can be read in and > played back by the TraceCPU. > > > Diffs > ----- > > src/cpu/o3/probe/elastic_trace.hh PRE-CREATION > src/cpu/o3/probe/elastic_trace.cc PRE-CREATION > src/proto/SConscript c0ea80fed78fef29ad2829b9d93e7bd568c46665 > src/proto/inst_dep_record.proto PRE-CREATION > src/proto/packet.proto c0ea80fed78fef29ad2829b9d93e7bd568c46665 > src/cpu/o3/probe/ElasticTrace.py PRE-CREATION > src/cpu/o3/probe/SConscript c0ea80fed78fef29ad2829b9d93e7bd568c46665 > > Diff: http://reviews.gem5.org/r/3027/diff/ > > > Testing > ------- > > > Thanks, > > Curtis Dunham > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
