CONTROLLER_PCREGIONS


Classes

class  CONTROLLER::PCREGION
struct  CONTROLLER::ROIpcinfoStruct
struct  CONTROLLER::ROIinfoStruct
class  CONTROLLER::CONTROL_PCREGIONS

Functions

INT32 CONTROLLER::CONTROL_PCREGIONS::Activate (BOOL passContext)

Detailed Description

Controller for "regions" that are specified using pc+count. Use -pcregions:in pcregions.csv

Regions are specified using a text file with the records of the form: # comment,thread-id,region-id,start-pc,start-pc-count,end-pc,end-pc-count, end-pc-relative-count, region-length, region-weight, region-multiplier, region-type [ fields after the first twelve are ignored, so are any lines beginning with '#' ]

end-pc-relative-count: is the count w.r.t. the beginning of the region. [ Corner case: if start-pc==end-pc, the first occurrence of the (common) pc is *not* counted in end-pc-relative-count. This to account for the fact that when used for relogging, the initial occurrence of the (common) pc will be skipped due to delay in region logging {unless '-log:precise_controller' is used} ]

region-type : "simulation"|"warmup"

Region weight can be computed two ways: 1. region-weight : number_of_slices_in_cluster/total_number_of_slices # Here, all slices are considered equal

2. alternate-region-weight : number_of_instructions_in_cluster /total_instruction_count # Here, slices with higher instruction counts contribute more.

If we use fixed-sized slices, both the weights are the same. However, with variable length intervals, they will be different.

The "BarrierPoint" paper used the second weight for their prediction. Also, since they were directly computing run-time, the introduced the idea of a region 'multiplier' region-multipler = alternate-region-weight * total_number_of_slices

That way: predicted_runtime = SUM( region_i_runtime * region_i_multiplier)

Knobs: ------ -pcregions:in foo.csv : input file -pcregions:end_only report only region ends -pcregions:relative use relative endPC-count -pcregions:merge_warmup ignore warmupEnd and regionStart -pcregions:no_warmup ignore warmup regions -pcregions:startpc_offset Add 'offset' to Start PCs of all regions -pcregions:verbose : for getting informed about regions/events -pcregions:out : Output file for regions skipped due to overlap The idea is to feed this file with "-pcregions:in" to the next invocation of the tool to process skipped regions. If this knob is specified but no regions are skipped, the output file will be empty.

Region processing: ----------------- The overall regions picture looks as follows: WARMUP--(SIM)REGION

each sub-region has a start and end event. So there are four events possible (two coinciding . warmup-end and sim-start) EVENT_WARMUP_START : Beginning of warmup region EVENT_WARMUP_STOP : End of warmup region EVENT_START : Beginning of interval EVENT_STOP : End of interval

Warmup region needs to specified explicitly in the pcregions file. For example, if we are using SimPoint output to generate the pcregion file, then the warmup could be N slices prior to the simulation region slice.

'region number' vs 'region id' o both > 0 o region number starts at one and goes till the number of regions in the input pcregions file. o region ids can be arbitrary numbers > 0 A pcregion file may have regions with ids sparsely assigned SimPoint generated cluster-IDs could be non-contiguous and region_id = cluster_id+1 This could also happen for example when the pcregion file contains regions skipped during a previous relogging session We use 'region number' value of zero to indicate an invalid ROI, so all *valid* 'region number' are > 1 and that's the reason we size ROIinfo array at 1+of_regions so we can index it starting at 1.


Function Documentation

INT32 CONTROLLER::CONTROL_PCREGIONS::Activate BOOL  passContext  )  [inline, inherited]
 

Activate the controller if the -pcregions knob is provided

Returns:
1 if controller can start an interval, otherwise 0


Generated on Sun Aug 27 14:28:11 2017 for Pin by  doxygen 1.4.6