Pin
Classes | Functions
CONTROLLER_PCREGIONS

Classes

class  CONTROLLER::PCREGION
 
class  CONTROLLER::CONTROL_PCREGIONS
 

Functions

BOOL CONTROLLER::CONTROL_PCREGIONS::Activate (BOOL passContext, CHAIN_EVENT_VECTOR **regionControlChains)
 

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" [ warmup region type contains also the parent region id of the simulation region for example - warmup:2 ]

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

  1. 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: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:image_offset Calculate addresses according to image name and offsets -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.

Function Documentation

◆ Activate()

BOOL CONTROLLER::CONTROL_PCREGIONS::Activate ( BOOL  passContext,
CHAIN_EVENT_VECTOR **  regionControlChains 
)
inline

Activate the controller if the -pcregions knob is provided

Returns
TRUE if controller can start an interval, otherwise FALSE