Data processing apparatus and method

Abstract

The processing circuitry 4 performs data processing operations in response to instructions or micro-operations fetched from the cache 16 or memory 34 or decoded from the instructions. The sampling circuitry 50 selects a subset of the instructions or micro-operations as sample operations to be subjected to performance analysis. The performance analysis circuitry 52 captures, in response to processing of the instructions or micro-operations selected as sample operations, sample records specifying the type of operation of the sample operation and information about the sample operation behaviour directly attributable to the sample operation. The performance analysis circuitry 52 can include, in the sample record for a sample operation corresponding to a given instruction, a reference instruction address indicator indicating the address of a reference instruction that occurs earlier or later in program order than the given instruction, for which control flow is sequential between any instructions that occur between the reference instruction and the given instruction in program order.

Description

BACKGROUND

[0001] The present technology relates to the field of data processing. More specifically, the present disclosure relates to performance analysis.

[0002] Processing circuitry performs data processing operations in response to instructions fetched from a cache or memory or micro-operations decoded from the instructions. The fetched instructions represent a program written or compiled to perform operations required by a software developer. To assist the software development, the developer can perform a performance analysis of the program in which information about the program's behaviour is captured as the program is processed by the processing circuitry so that the information can be analysed to identify parts of the program that can cause poor performance and possible causes of the poor performance. The results of the performance analysis can be used by the software engineer to optimise their software to reduce execution time and allow better utilisation of the available resources in the processing system.

[0003] At least some examples provide an apparatus comprising:

[0004] processing circuitry to perform data processing operations in response to instructions fetched from a cache or memory or micro-operations decoded from the instructions;

[0005] sampling circuitry to select a subset of the instructions or micro-operations as sample operations to be subjected to performance analysis; and

[0006] performance analysis circuitry to capture, in response to processing of the instructions or micro-operations selected as sample operations by the sampling circuitry, sample records specifying a type of operation of the sample operations and information about behaviour of the sample operations directly attributable to the sample operations; wherein:

[0007] the performance analysis circuitry is capable of including in the sample records captured for a sample operation corresponding to a given instruction a reference instruction address indicator indicating an address of a reference instruction that occurs earlier or later in program order than the given instruction for which control flow is sequential between any instructions occurring between the reference instruction and the given instruction in program order.

[0008] At least some examples provide a method comprising:

[0009] performing data processing operations in response to instructions fetched from a cache or memory or micro-operations decoded from the instructions;

[0010] selecting a subset of the instructions or micro-operations as sample operations to be subjected to performance analysis; and

[0011] to capture, in response to processing of an instruction or micro-operation selected by the sampling circuitry for a sampling operation, a sample record specifying an operation type of the sampling operation and information about the sampling operation behaviour directly attributable to the sampling operation; wherein:

[0012] The performance analysis circuitry is able to include in the sample record captured for a sampling operation corresponding to a given instruction a reference instruction address indicator indicating an address of a reference instruction which appears earlier or later in program order than the given instruction, for which control flow is sequential between any instructions occurring in program order between the reference instruction and the given instruction. BRIEF DESCRIPTION OF DRAWINGS

[0013] Further aspects, features, and advantages of the present technology will be apparent from the following description of examples, as read in conjunction with the attached drawings, in which:

[0014] Figure 1 An example of a data processing apparatus having performance analysis circuitry is shown schematically;

[0015] Figure 2 Sampling of instructions or micro-operations for selection of operations for which sample records are to be captured is shown;

[0016] Figure 3 A flowchart showing capture of sample records for sampling operations and filtering of whether sample records are accessible for diagnostic analysis;

[0017] Figure 4 A plurality of grouping types which can be included in sample records is shown;

[0018] Figure 5 An example of a sample record including a plurality of groupings is shown;

[0019] Figure 6 An example of an address grouping which can be included in a sample record is shown;

[0020] Figure 7 An example of a sequence of program instructions including branch instructions is shown;

[0021] Figures 8 to 11 An example of generating an address grouping including a reference instruction address for an example sequence of Figure 7

[0022] Figure 12 A flowchart showing a method of using a trace instruction indicator to track which address should be indicated as a reference instruction address for a subsequent sampling operation;

[0023] Figure 13 ​is a flowchart showing the use of a trace instruction indicator to show a reference instruction address indicator for setting a sampling operation; and

[0024] Figure 14 is a flowchart showing a second example of setting a reference instruction address indicator, where the reference instruction address indicator indicates an address of an instruction later in program order than an instruction associated with a sampling operation. DETAILED DESCRIPTION

[0025] A problem encountered in performance analysis of program execution on a processor is that the processor can execute millions of operations per second or billions of operations per second, and it is therefore not feasible to keep detailed records of the precise instruction-by-instruction behavior of every instruction executed. One approach to performance analysis can be to define a number of performance monitor counters that count certain events, such as cache misses or branch misses that can affect poor performance, and when a given number of such events have been detected, generate a performance monitor interrupt to cause an exception handling routine to read architectural state from registers or other performance monitor information, which can then be accessed for diagnostic analysis. However, a problem with this approach is that it requires interrupting regular program flow in order to collect information at frequent sampling intervals, which requires a high interrupt rate that can affect the normal running of the program and make the results of the diagnostic analysis less meaningful, as the observed behavior can not be consistent with the behavior that would have occurred if the performance analysis had not been performed. Indeed, another problem is that there can be a "sliding" delay between the time that the performance monitor interrupt is signaled and the time that the exception handler begins collecting the captured architectural state or performance monitor information, and during the intervening time period, the processor can continue to execute hundreds of other instructions, so that the captured information cannot be directly attributed to the operation being performed at the point that the interrupt was triggered. Also, with event-driven capture of performance analysis information, the events themselves do not give a very accurate indication of location. To optimize code, engineers can need precise information about where the problem is (such as control plane problems), exactly which instruction, line of code, class and / or module is affected, or call stack and / or path leading to that instruction, as ordinary profiling is often unenlightening; and for data plane problems, which variable, array or object is affected. This can be difficult to identify through typical event-triggered sampling techniques.

[0026] In the example described below, processing circuitry performs data processing operations in response to instructions fetched from cache memory or micro-operations decoded from instructions. Sampling circuitry selects a subset of the instructions or micro-operations as sampling operations to be performance analyzed. Performance analysis circuitry captures sample records specifying an operation type of the sampling operation and information about sampling operation behavior directly attributable to the sampling operation in response to processing of the instructions or micro-operations selected as sampling operations by the sampling circuitry.

[0027] By this approach, when the sample records capture information directly attributable to the sampling operation, this avoids the skid problem caused by the interrupt-based profiling mechanism as discussed above. The information included in the sample records can directly indicate events that occurred during the processing of the sampling operation, such as whether a cache miss occurred at a given level of cache or whether a branch misprediction occurred for a given branch, or can indicate the cycle counts measuring the delay of certain events during the processing of the sampling operation. However, when the sampling circuitry only selects a subset of instructions or micro-operations as the sampling operation, this greatly reduces the hardware and power overhead of collecting information on the sampling operation. The sample records captured for the sampling operation can provide a statistical view of the program performance as a whole, rather than attempting to capture the behavior of every operation. By indicating the operation type of each sampling operation in the corresponding sample record, there is no need to provide any restrictions on what type of sampling operation the sampling circuitry will select as the sampling operation, such that the sample records are not limited to capturing information on a single predetermined type of sampling operation. This can assist in monitoring two or more different issues in a single set of sampling information using a single performance analysis run (rather than using event-triggered sampling where the capture of information is fixed for a particular event). Furthermore, providing a sampling circuitry that selects particular instructions or micro-operations as the sampling operation to be profiled can enable tracking of events that occur at different stages of the pipeline as the sampling operation passes through the pipeline, which can not be possible in examples where the capture of architectural state or performance monitoring counters is based on the occurrence of a particular event, where the information can not be directly attributable to a particular operation but can be based on a number of different operations.

[0028] The sampling circuitry and performance analysis circuitry can be used to provide detailed information about the results and performance of particular operations processed by the processing circuitry, which can be useful in identifying possible causes of poor performance when executing a given program. However, another aspect of performance analysis can be to identify which parts of the program code are executed more frequently than others. A software developer can only have a limited amount of time available for code optimization, and can wish to focus their time on improving the performance of more frequently executed parts of the code over less frequently executed parts of the code. It can be considered that with a sampling-based approach for performing performance analysis, it would be difficult to analyze the frequency of execution of different parts within a program, as sampling means that many operations are not tracked in the sample records captured for the sampling operation, such that each sample record only provides an indication of the execution of a single instruction, and would not provide information on how the program reached that instruction and what path via the control flow. It can therefore be considered that a sampling-based approach would require capturing a very large number of samples to provide meaningful hotspot performance analysis information on relative frequency of execution, which can incur too high a cost in terms of the storage and data output overhead of generating such a large amount of sampling information.

[0029] In the examples described below, the performance analysis circuitry can be able to include in the sample record captured for a sample operation corresponding to a given instruction a reference instruction address indicator indicating the address of a reference instruction that occurs earlier or later in program order than the given instruction, for which the control flow between any instructions occurring between the reference instruction and the given instruction is sequential. The performance analysis circuitry can be inhibited from setting the reference instruction address indicator to the address of an instruction for which there is a non-sequential change in control flow between any two instructions occurring between the reference instruction and the given instruction (the given instruction can be a taken branch instruction, so this does not prevent there being a non-sequential change in control flow between the given instruction and the immediately following instruction - in this case the reference instruction address can still indicate the address of a later instruction than the given instruction, provided there is no subsequent non-sequential change after the branch taken by the given instruction).

[0030] Thus, by including in the sample record for a given sample operation an indication of the address of an instruction for which the control flow is sequential up to or after the given instruction, this allows a single sample record to provide evidence of execution of an entire range of instruction addresses, greatly reducing the number of sample records that need to be captured to provide sufficient information to produce a statistically meaningful hotspot profile indicating the relative frequency of execution of different parts of a program. This reduces the amount of performance analysis data required compared to sample-based performance analysis methods that do not support the use of reference instruction address indicators. As a result, program optimisation by software developers can be more effective. However, unlike alternative trace-based techniques for generating program flow profiles that only capture information about the control flow paths taken but do not indicate any other information, the sample records captured can also indicate other non-control flow information, such as event or cycle counts, which can enable a single diagnostic execution run to collect performance analysis information for multiple purposes.

[0031] In some examples, the performance analysis circuitry can be able to set the reference instruction address indicator to indicate the address of an earlier instruction that occurs earlier in program order than the given instruction, for which the control flow is sequential from the earlier instruction to the given instruction. In terms of the logic of the hardware circuitry used to track the reference instruction address, this approach can be simpler to implement. For example, a storage element can be provided that can be reset upon identification of an instruction representing one of a plurality of types of event that can be used to mark a reference instruction, and used to track the address of the instruction at the point of reset or the number of instructions seen since the point of reset. When a subsequent sample operation is encountered, the value tracked in this storage element can then be used to set the reference instruction address indicator in the sample record for the sample operation.

[0032] However, other examples can provide performance analysis circuitry that is able to set the reference instruction address indicator to indicate an address of a later instruction that occurs later in program order than the given instruction for which the control flow is sequential from the next instruction after the given instruction to the later instruction. With this approach, the reference instruction address indicator effectively gives a view of how far beyond the given instruction, the next sequential block of control flow continues before reaching a non-sequential change in control flow or other event requiring the tracking of reference instructions to stop.

[0033] Some embodiments can support both options, where the reference instruction address indicator can provide an indication of an address of an earlier instruction or an address of a later instruction (e.g., to select an indication of the longest run of sequential execution to provide the maximum possible number of "instruction execution counts" of a hot spot profile), or can indicate both types of reference instruction address indicators in the same sample record to provide more information about control flow before or after the given instruction corresponding to the sampling operation. However, in many embodiments, it can be sufficient to track control flow in only one direction relative to the given instruction (either looking back only to earlier instructions in program order, or looking forward only to later instructions in program order) to limit the hardware cost of tracking of reference instruction addresses.

[0034] The performance analysis circuitry can set the reference instruction address indicator to indicate a branch target address of a most recent taken branch instruction before the given instruction or to indicate an instruction address of a next taken branch instruction after the given instruction. Since a taken branch instruction represents a point where there is a non-sequential change in control flow, using the reference instruction address indicator to give an indication of the most recent or next branch can give the maximum amount of information about the size of the sequential run of instructions executed before or after the given instruction, giving a larger number of "instruction execution counts" that can contribute to a hot spot profile. Thus, if looking back to earlier instructions before the given instruction, the reference instruction can be the instruction at the branch target address of the most recent taken branch instruction, while if the reference instruction address indicator is used to look forward to later instructions after the given instruction, the reference instruction can be the next taken branch instruction after the given instruction itself.

[0035] However, in practice, the present inventors have recognised that whilst the use of a reference instruction address indicator to indicate the location of a most recent or next taken branch can enable a larger block of sequentially processed instructions to be indicated, in some (but not all) performance analysis scenarios, the approach of always using the taken branch location to set the reference instruction address indicator can give a biased result for hot spot performance analysis. Thus, it can be useful to provide a performance analysis circuit which also supports the ability to set the reference instruction address indicator to indicate the instruction address of an instruction other than the following instructions at the branch target address of the most recent taken branch instruction before the given instruction, and at the instruction address of the next taken branch instruction after the given instruction. More specifically, it can sometimes be useful to be able to set the reference instruction indicator to indicate the instruction address of one of the following: an instruction to which program flow is directed after the most recent branch instruction before the given instruction, regardless of whether the most recent branch instruction is taken or not; or the instruction address of the next branch instruction after the given instruction, regardless of whether the next branch instruction is taken or not.

[0036] It can be considered counter-intuitive to use the reference instruction address indicator to indicate the location of a previous / next not-taken branch instruction, since there will be other instructions which are sequentially executed before or after the not-taken branch, and thus such an approach can seem to forgo the opportunity to increase the range of instructions which can be confirmed as having been executed by the contents of a single sample record. However, as explained in more detail below, if samples of taken and not-taken branches only reference the taken branch record reference instruction address indicator, and the resulting reference instruction address indicator is used for hot spot performance analysis, this can result in the resulting hot spot performance analysis incorrectly indicating that a section of code on one side of a consistent not-taken branch is executed more frequently than another section of code on the other side of the consistent not-taken branch, even if both sections of code are executed an equal number of times. This problem of skewed performance analysis results can be prevented by using the location of the previous branch or next branch to set the reference instruction address indicator, regardless of whether the branch is taken or not. For some performance analysis scenarios, this can give a more accurate indication of the relative frequency of execution of a particular set of instructions.

[0037] However, when this problem does not arise (for example, if samples of not-taken branches are not output for analysis), there are other performance analysis scenarios, and in that case, it can be preferable to use the earlier / later branch as the reference for generating the reference instruction address indicator.

[0038] In this application, unless otherwise indicated, terms such as "earlier," "later," "next," "most recent," "preceding," "prior," or "following" that define a relative ordering of instructions refer to the order in which the instructions appear in program order. Program order refers to the order in which instructions would be executed in an in-order processor. In other words, program order corresponds to the order defined by the programmer or compiler that created the program. The fetch stage of the processing circuitry can fetch instructions for execution in program order. Some implementations can use an in-order processing circuitry that also executes instructions or micro-operations in an order corresponding to program order. However, in other examples, the processing circuitry can be an out-of-order processing circuitry that is capable of reordering instructions / micro-operations to allow for instructions or micro-operations to be processed in an order different from program order. For example, a later instruction in program order can be executed before an earlier instruction in program order if the later instruction is ready to be executed before the earlier instruction, depending on the timing at which operands become available and the dependencies between instructions. Thus, for the purposes of tracking the reference instruction address indicator, the terms referring to the relative order between instructions refer to program order. This does not preclude the processing circuitry from executing instructions in a different order. For example, in some cases, a most recent branch in program order can actually be executed after an earlier branch in program order, depending on the timing at which operands become available and the dependencies between instructions.

[0039] One way of selecting which addresses to indicate as reference instruction addresses can be to define a particular type of reference instruction address reset event that indicates that the address associated with the reference instruction address reset event should be recorded as the reference instruction address for a later or earlier sampled operation. In the example where the sample records specify an address of an instruction earlier than the given instruction as the reference address, the reference instruction address indicator can be set to the address associated with the most recent reference instruction address reset event that occurred before the given instruction. In the example where the sample records specify an address of an instruction later than the given instruction as the reference address, the reference instruction address indicator can be set to the address associated with the next reference instruction address reset event that occurs after the given instruction.

[0040] As noted above, the position of the most recent or next taken branch instruction in program order relative to a given instruction can generally represent the maximum range before or after the given instruction that would be allowed to be identified using the reference instruction address indicator. Thus, it can be useful for the performance analysis circuitry to detect the processing of a taken branch as a reference instruction address reset event.

[0041] However, there can be one or more other types of reset events that can reset the tracking of the reference instruction address such that if a reference instruction address reset event occurs between the taken branch instruction and the given instruction, the reference instruction address indicator can instead be set to mark the position of the instruction corresponding to the point at which the reset event occurred.

[0042] For example, processing of a miss-taken branch can also be detected as a reference instruction address reset event, such that if there is a miss-taken branch between a given instruction and the most recent / next taken branch, the reference instruction address can instead point to an address associated with the miss-taken branch operation. By supporting the option of referring to the address of a miss-taken branch (or the address of the instruction following the miss-taken branch) as the reference instruction, this can help improve the statistical validity of the hotspot performance analysis results, such that the hotspot performance analysis measurements derived from the sample record set by the hotspot performance analysis represent the actual relative execution frequencies of different instruction blocks. The following references Figure 7 A more detailed explanation is provided of the reasons why miss-taken branches are used as such reset events to avoid statistical bias.

[0043] In some implementations, processing of a miss-taken branch can always be treated as a reference instruction address reset event.

[0044] However, other implementations can provide configuration information (e.g. stored in a configuration register) which can be configured by software or an external device to define whether processing of a miss-taken branch should be detected as a reference instruction address reset event. The performance analysis circuitry can determine whether a miss-taken branch should be detected as a reference instruction address reset event based on the configuration information. For some forms of analysis (e.g. when miss-taken sample records are to be discarded before output or output but not used in the analysis), it can only be acceptable for the reference instruction address indicator to indicate relative to taken branches, so by configuring the performance analysis circuitry such that miss-taken branches are not treated as reference instruction address reset events, this can allow the reference instruction address indicator to indicate a larger range of sequentially executed instructions extending through miss-taken branches to taken branches, giving more instruction counts available for hotspot performance analysis. By contrast, if the analysis is to be performed with the risk of biasing the performance analysis results unless the reference address tracks miss-taken branches, the configuration information can be set to indicate that miss-taken branches should be detected as reference instruction address reset events. By providing configuration information to control whether miss-taken branches are treated as reset events, this gives flexibility to change the approach taken to adapt to the type of analysis being performed.

[0045] In some examples, the apparatus can have a filtering circuit that controls whether sample records captured by the performance analysis circuit for a sample operation are made available for diagnostic analysis based on whether the sample operation satisfies at least one filtering criterion. Not all sample records captured by the performance analysis circuit can be relevant to the purpose for which the performance analysis is being performed and so the filtering circuit can be configurable to ensure that only particular types of sample records become available for diagnostic analysis in order to conserve capacity or bandwidth of resources used to store and output sample records. For example, sample records can be made available for diagnostic analysis in different ways, such as by writing the sample records to memory from which they can be read by other circuitry executing on the processing circuit under debug, by outputting the sample records to an on-chip trace buffer on the chip, and / or by outputting the sample records through a trace port to an external device that stores the sample records or uses the sample records to perform diagnostic analysis. Some systems can support more than one of these forms of making sample records available for diagnostic analysis. Regardless of which form is supported, by providing filtering based on at least one filtering criterion (which can be configured by a user by adjusting filter configuration data stored in configuration registers associated with the performance analysis circuit), this can allow a software developer to control what types of sample records are captured.

[0046] In one example, the configuration information used to determine whether a branch not taken should be treated as a reset event can be filtering criterion configuration information that also controls one or more filtering criteria of a filtering circuit. For example, a user can treat the configuration information as a filtering criterion, but for certain settings of the filtering criterion, the performance analysis circuit can treat a branch not taken as a reset event, while for other settings of the filtering criterion, a branch not taken can not be treated as a reset event. For example, if the filtering criterion is set so that sample records for branch not taken operations are allowed to be available for diagnostic analysis, and a reference instruction address indicator is to be included in sample records captured for branch not taken operations, then the performance analysis circuit can detect processing of a branch not taken operation as a reference instruction address reset event (regardless of whether the branch not taken operation itself is selected as a sample operation). If the filtering criterion is set to indicate that sample records for branch not taken operations are not to be made available for diagnostic analysis, or if sample records for branch not taken operations are not to include a reference instruction address indicator, then processing of a branch not taken operation need not be treated as a reset event.

[0047] However, in other examples, the configuration information used to determine whether to treat a not-taken branch as a reset event can be defined separately from any configuration information that sets the filtering criteria of the filtering circuit. In such cases, there can be orthogonal control of the types of reset events that will be detected as reset reference instruction address traces, and the filtering criteria that will be used by the filter. When considering the risk of biasing the performance analysis results, it can be up to the user (or the software implementing the performance analysis) to determine which combination of reset event / filter settings is the type of setting that they wish to perform the analysis for.

[0048] Other types of reference instruction address reset events can include:

[0049] • the enabling of performance analysis by the performance analysis circuit after performance analysis has been previously disabled. If performance analysis is disabled for a certain time, it can be that no previously occurring taken branches are tracked, so the point of reference for the reference instruction address can be the point at which performance analysis is enabled.

[0050] • the taking of an exception and / or returning from an exception. This recognises that during the processing of an exception handler that interrupts the processing of the program for which performance analysis is being performed, it is possible that instructions within the exception handler can cause some tracking resources of the performance analysis circuit to change state (including any tracking resources used to track the reference instruction address indicator) and so on return from the exception, the tracking of previous taken branches can no longer be reliable. Therefore, in order to provide valid performance analysis results, it can be preferable to reset the tracking of the reference instruction address on taking the exception or on return from the exception.

[0051] • Furthermore, sometimes the processing of a sample operation itself can be treated as a reference instruction address reset event. For example, when the sample operation is a taken / not-taken branch, and the reference instruction address indicator is captured in the sample record to indicate the address of a reference instruction later / earlier than the taken branch instruction, the address of the taken branch instruction itself (or the next instruction after the taken branch) can be recorded to be used as the reference address for another sample operation.

[0052] Not all implementations need to support all of these types of reset events. Additionally, some implementations can support configuration information that defines which types of events cause a reset (at least for some forms of reset event). Furthermore, for some types of reset events (e.g. the processing of a sample operation), although sometimes the event can cause a reset, in other cases the event can not cause a reset (e.g. whether the event is a reset event can also depend on other conditions).

[0053] An alternative to resetting the tracking of reference instruction addresses in response to the other types of reset events discussed above (the enabling of performance analysis, taking an exception / returning from an exception, processing of a sample operation) can be to instead invalidate the tracking of reference instruction addresses at the occurrence of such events. In this case, the reference instruction address indicator can be valid and indicate the location of a taken or not-taken branch (or instruction following a taken or not-taken branch), or invalid if one of the invalidation events that indicate that the reference address indicator can not be reliable occurs, such as when the enabling of performance analysis or a take exception / return event occurs. Additionally, to simplify the microarchitectural implementation of the capture of information within the sample records, it can be useful, although not necessary, to treat the processing of the sample operation itself as a reference instruction address invalidation event, as the sample operation can typically have the same type as one of the instruction types that can be detected as a reference instruction (e.g., the sample operation itself can be a taken / not-taken branch), and thus the sample operation itself can cause a reset of the reference instruction address as discussed above. Thus, it can be desirable to ensure that any previously set reference instruction address is captured for the sample record to be output for the sample operation before resetting the reference instruction address in response to the sample operation itself, but this can create a challenge in managing the timing of the capture / reset. One way to prevent the previously tracked address from being overwritten before it has been captured in a sample record can be to suppress the sample operation itself from being used as a reference instruction, as it is sampled, and thus leave the reference instruction address unchanged in response to the sample operation. Given that the sample interval is typically expected to be significantly larger than the interval between consecutive reference instruction address reset events (e.g., branches), it is very unlikely that the reference instruction address is not reset before the next sample operation is encountered, but to be sure (and to avoid the risk of a subsequent sample operation potentially referencing a reference address for which there is an intermediate non-sequential change in program flow), the reference instruction address can be invalidated in response to the sample operation, after it has been transferred to the sample record for the sample operation.

[0054] It will be noted that whilst the performance analysis circuitry is able to indicate an address of an instruction in program order that is earlier or later than the given instruction stored in the sample record for a given instruction, in some cases the reference instruction address indicator can end up indicating the address of the given instruction itself. For example, in the example where the reference instruction address indicator is set to indicate the branch target address of a taken / not-taken branch instruction, then if the sampling circuitry selects as a sampling operation an instruction at the branch target address of a taken branch or sequentially after a not-taken branch, then the reference instruction address indicator will indicate the address of the given instruction itself. Thus, whilst the performance analysis circuitry is able to encode the reference instruction address indicator so that it indicates an address of an instruction in program order that is earlier or later than the given instruction, this does not preclude that sometimes the performance analysis circuitry can use the reference instruction address indicator to indicate the address of the given instruction itself.

[0055] In some implementations, the performance analysis circuitry can be able to include the reference instruction address indicator in sample records captured for any type of sampling operation, regardless of the type of instruction corresponding to the sampling operation.

[0056] However, in practice, in order to avoid statistical bias of the type discussed above, it can be desirable for the reference point for reference address tracking to be selected from the same population of operation types for which the sample records will provide the reference instruction address indicator. Thus, if any operation type is allowed to provide sample records including reference instruction address indicators, then when a large number of samples will be able to count towards hot spot performance analysis, in order to ensure statistically unbiased results in practice it can be necessary for the reference instruction address indicator to be used as a reference to the location of the most recent / next processing instruction of any operation type, which limits the range of earlier / later instructions that can be indicated by the reference instruction address indicator in a single sample record.

[0057] Thus, in order to increase the range of instructions that can be indicated as being performed by a reference instruction address indicator in one sample record in achieving unbiased performance analysis results, it can be preferable to restrict the reference instruction address indicator to only be included in sample records for a particular subset of instruction types, such that the reference instruction address indicator can look further forward / backward in program order from a given instruction without biasing the performance analysis results.

[0058] In one example, the reference instruction address indicator can be included in the sample record captured from a sample operation corresponding to a given instruction at least when the given instruction is a taken or not-taken branch instruction. Some examples can include the reference instruction address indicator only for taken branch instructions, but not for not-taken branch instructions. Other examples can support tracking the reference instruction address indicator in sample records for both taken and not-taken branch instructions (and in this case, it can be desirable to have the processing of sampled or unsampled not-taken branch operations reset the tracking of the reference instruction address, as discussed above). Which types of instructions cause the reference instruction address indicator to indicate whether the instruction was selected as a sample operation can be fixed in hardware, or can be variable so that a user can configure (e.g., through configuration information in configuration registers) which types of instructions should have their sample records include the reference instruction address indicator.

[0059] Such configuration information can also control whether the reference instruction address indicator should be included in sample records at all (for any type of operation). It is not necessary for the performance analysis circuitry to always operate so that the reference instruction address indicator is included in sample records. When the performance analysis configuration information specifies that capture of the reference instruction address indicator is disabled, the performance analysis circuitry can omit the reference instruction address indicator. When the performance analysis configuration information specifies that capture of the reference instruction address indicator is enabled, the reference instruction address indicator can be included (but can also be omitted for other reasons, e.g., because a reference instruction address invalid event has occurred as described above). Thus, a user can choose whether the reference instruction address indicator is of interest to trade off the ability to perform hotspot performance analysis against the savings in diagnostic storage / bandwidth.

[0060] In some examples, sample records can have a packetized format, in which a sample record can include one or more packets. The number of packets in one sample record can be fixed, or can be variable depending on the implementation. By providing a packetized format, this gives flexibility to different microarchitecture designers to select different formats as needed, while still conforming to a particular architectural definition of the packet, so that software can interpret the packets in a consistent manner regardless of the particular format of the sample record for a particular implementation. Different types of packets can be defined to indicate different types of information that can be recorded within a sample record. One of these types of packets can be an address packet that specifies an address associated with a sampling operation. An address packet can have a packet header that identifies that the packet is an address packet (distinguishing from other types of packets that do not provide an address), but it can also specify what type of address is associated with the sampling operation. This can be done in different ways, such as having a first header portion that identifies the packet as an address packet and a second portion that serves as an address type indicator, or by having a single combined header value that identifies the packet as an address packet and also serves as an address type indicator (in this example, multiple different values of the packet header that correspond to different address type indicators can all be considered as headers of address packets).

[0061] The address type indicator of an address packet can have multiple valid encodings, including a reference instruction address encoding that indicates that the corresponding address packet specifies a reference instruction address indicator, and at least one other encoding that indicates that the address packet specifies an address other than a reference instruction address indicator. By allocating a dedicated encoding for the address type indicator of an address packet that specifies a reference instruction address, this enables diagnostic analysis tools to extract reference instruction addresses from various sample records and use these for performance analysis.

[0062] As noted above, the sample records captured by the performance analysis circuitry can be made available for diagnostic analysis. In one example, the sample records can be made available by writing the sample records to memory using a sample record write circuit. The sample record write circuit can be able to write sample records captured by the performance analysis circuitry to memory while the processing circuitry continues uninterrupted processing. Thus, unlike the interrupt-based approach discussed previously, sample records can be initially captured in hardware storage elements of the performance analysis circuitry and then written out to memory, which is typically accessed by load / store instructions executed on the processing circuitry, without the need for specific store instructions to be executed in software by the processing circuitry to cause sample records to be saved to memory. This greatly reduces the impact of performance analysis on the performance of code executed on the processing circuitry and avoids the interruption of performance monitoring targets that causes artefacts in the collected performance analysis information. For example, rather than generating an interrupt each time a sample record is generated, a buffer structure can be maintained in memory of a particular size sufficient to store a particular number of sample records and once the buffer in memory is at risk of overflowing, an interrupt needs to be triggered.

[0063] The filtering circuitry can be arranged to determine whether the sample record write circuitry should write a sample record captured by the performance analysis circuitry for a sample operation to memory based on whether the sample operation meets at least one filtering criterion. The filtering criterion can be based on the type of sample operation, or based on information within the sample record itself. For example, if a software developer is interested in the causes of, for example, mispredictions, the filtering criterion can specify that only sample records for mispredicted branches should be written to memory, but sample records captured for correctly predicted branches do not necessarily need to be written to memory. Alternatively, the filtering criterion can be based on whether there is a particular level of cache misses for load operations, or whether the instruction address of the sample operation is within a given address range, etc. The filtering circuitry can support a wide range of filtering criteria.

[0064] One option for the filtering criterion can be a criterion that the sample operation corresponding to a given sample record is a taken branch operation. This can be useful for hotspot performance analysis. By only recording sample records for taken branches that represent points of non-sequential program flow, this allows the use of the reference instruction address indicator to refer to the branch target address of the most recent taken branch or the instruction address of the next taken branch (without skewing the hotspot performance analysis results) such that the maximum possible range of earlier / later instructions can be indicated as executed from each sample, enabling the maximum possible amount of hotspot performance analysis for a given number of sample records. However, in addition to hotspot performance analysis, tracking only taken branches can not allow other forms of performance analysis to be performed on the same set of sample records.

[0065] In another example, the filtering circuitry can be configurable to specify as one of the at least one filtering criteria a criterion that the sampling operation corresponding to a given sample record is to take a branch operation or not take a branch operation. By providing the ability to ensure that sample records for both taken and not taken branch operations are saved to memory or otherwise made available for diagnostic analysis, while excluding other sample records related to operations that are not taken or not taken branches, this can allow hot spot performance analysis to be performed using the reference instruction address indicators included in the taken / not taken branch sample records, while also supporting other types of performance analysis based on the same execution run (e.g., analysis of poor performance caused by mispredicted branches can be more reliable if both taken and not taken branches are included in the output for diagnostic analysis). Thus, a set of sample records captured for a single instance of an executing program can be used for two purposes (rather than needing to perform two separate execution runs, one tracking taken branches for hot spot performance analysis and another tracking mispredicted branches). When the filter is configured to output samples for both taken and not taken branches, then if the reference instruction address indicator is included in both taken branch events and not taken branch events, then the reference instruction address tracking is expected to skew relative to taken or not taken branches to avoid hot spot performance analysis for the reasons described above.

[0066] The sampling of operations by the sampling circuitry can be controlled in different ways. For example, the sampling circuitry can select instructions at the fetch stage or decode stage of the processing pipeline or at a later pipeline stage. However, by selecting the sampling operations at a relatively early stage of the pipeline (such as fetch or decode), events associated with those sampling operations can be tracked through the useful life of the processing of the operations in subsequent stages.

[0067] The sampling circuitry can select the next sampling operation in response to the passage of a sampling interval counted by an interval counter. The interval counter can count different forms of operations to determine when to select the next sampling operation. For example, the interval can be counted based on the number of instructions fetched from a cache or memory, the number of instructions decoded by an instruction decoder, or the number of micro-operations generated by the decoder to execute.

[0068] The sampling circuitry can support random perturbation of the sampling interval, such that if random perturbation of the sampling interval is enabled, the performance analysis circuitry can adjust the sampling interval by a random or pseudo-random value to set the sampling interval counted by the interval counter in a given period. For example, the sampling interval can be configured by a user (by setting control data in a register) to specify a nominal number of instructions or micro-operations to be counted between two successive sampling operations, but this nominal value can be adjusted by a random / pseudo-random value to cause the exact interval in one count period to vary compared to the next. This reduces the risk that the sampling circuitry can repeatedly select the same operations within a program loop through multiple iterations of the loop, which can risk skewing the performance analysis results.

[0069] The reference instruction address indicator can be represented in a variety of ways. In general, the reference instruction address indicator can be any value that enables the address of the reference instruction to be identified. In one example, the reference instruction address indicator can be the absolute value of the address of the reference instruction. Another example can be that the reference instruction address indicator specifies a relative offset of the address of one of the given instruction and the reference instruction relative to the address of the other. This approach can help to compress the amount of data required in the sample record, as a relative offset can typically be expressed using fewer bits than the absolute value of the address of the reference instruction. In another example, the reference instruction address indicator can indicate the number of instructions between the given instruction and the reference instruction in program order.

[0070] Figure 1 An example of a data processing apparatus 2 comprising processing circuitry 4 for performing data processing is shown schematically. The processing circuitry 4 comprises a processing pipeline having a plurality of pipeline stages, in this example including fetch, decode stage 8, issue stage 10, execution stage 12 and writeback stage 14 of data 6. It will be appreciated that this is merely one example of a possible pipeline configuration, and other examples can have a different number of stages and can include additional types of pipeline stage.

[0071] The fetch stage 6 fetches instructions from a level 1 instruction cache 16 for execution by the pipeline. A branch predictor 18 provides a prediction of the outcome of branch instructions, which can be used by the fetch stage 6 to decide which instructions to fetch beyond a branch. The instructions fetched by the fetch stage 6 are decoded by the decode stage 8 to generate control signals for controlling later pipeline stages to perform the operations represented by the instructions. The decode stage 8 can map the instructions to micro-operations, which represent the operations to be performed at the granularity of micro-operations executable by the execution stage 12.

[0072] In some pipeline implementations, there is always a one-to-one mapping between instructions fetched from memory and micro-ops, as seen in later stages, so the micro-ops can simply be seen as equal to or representing the original instructions fetched (although the micro-ops can still be represented in different form from the corresponding instructions - for example, the micro-ops can be tagged with additional information, such as "sampled operation" tags as described below). Such pipeline implementations can be seen as either directly executing instructions (without the need to decode instructions into micro-ops, since there is no change in mapping) or as executing micro-ops that are decoded from instructions through a one-to-one mapping. Both views can be seen as equivalent descriptions of the same pipeline.

[0073] In other examples, for at least some instructions, the pipeline can support a one-to-many or many-to-one mapping of instructions to micro-ops. Some instructions can still correspond to a single micro-op. Other instructions can be split into multiple micro-ops by the decode stage 8. The decode stage 8 can also support the fusion of two or more program instructions fetched from the cache 16 to form a single combined micro-op that is supported by the execution stage 12. Thus, the micro-ops seen by the execution stage 12 can be different from the architecture definitions of the instructions defined in the instruction set architecture supported by the data processing apparatus 2.

[0074] In the following description, the term "micro-op" refers to the form of the instruction as seen at the execution stage. This can simply be the original instruction itself for some pipelines, or can be a modified form of the instruction or a micro-op obtained by splitting one instruction into multiple micro-ops or fusing multiple instructions into a combined micro-op.

[0075] The issue stage 10 queues the micro-ops generated by the decoder 8 and waits for the operands to become available, and issues the micro-ops for execution when their operands are available (or when it is known that the operands will become available at the time the micro-op reaches the relevant cycle of the execution stage that requires the operand). The execution stage 12 includes multiple execution units 22-28 for executing different types of micro-ops. The processing operations are performed by the execution units 22-28 based on operands read from the registers 20. For example, the execution units of the execution stage 12 can include an arithmetic / logic unit (ALU) 22 for performing arithmetic or logical operations, a floating point unit 24 for performing operations involving numbers represented as floating point values, a branch unit 26 for determining whether a branch instruction should be taken or not taken and for adjusting the program flow to perform a non-sequential change in program flow when a branch is taken, and a load / store unit 28 for handling load operations (for loading data from a memory system into the registers 20) and store operations (for storing data from the registers 20 to a memory system). It will be appreciated that Figure 1The particular set of execution units 22-28 shown in the execution stage 12 in this example is just one possible arrangement, and other examples can have different types of execution units or can have multiple execution units of the same type (e.g., multiple ALUs 22). The write back stage 14 writes the results of the executed instructions back to the registers 20.

[0076] The processing pipeline 4 can be an in-order processing pipeline that is constrained to execute micro-ops in an order that corresponds to program order, where the instructions are defined by a programmer or compiler and where the instructions are fetched by the fetch stage 6. Alternatively, the processing pipeline 4 can support out-of-order processing, where the issue stage 10 is allowed to issue micro-ops for execution in an order that can be different from program order. For example, while one micro-op stalls and waits for its operand to become available, a later micro-op associated with a later instruction in program order can be executed before the stalling instruction. If the pipeline supports out-of-order processing, an additional pipeline stage such as a rename stage can be provided to remap architectural register specifiers specified by decoded program instructions to physical register specifiers that identify specific hardware registers in the register set 20.

[0077] In this example, the memory system includes a level 1 instruction cache 16, a level 1 data cache 30, a shared level 2 cache 32 that can be used for both data and instructions, and a main memory 34 that can include multiple memory storage units, peripheral devices, and other devices that can be accessed via load / store instructions executed by the pipeline 4. It will be appreciated that, Figure 1 The particular cache hierarchy shown is just one example, and other examples can have a different number of cache levels, or can provide a different arrangement of instruction caches relative to data caches (e.g., the level 2 cache 32 can be split into separate level 2 instruction and data caches). A memory management unit 36 is provided for controlling address translation between virtual addresses (generated based on operands of instructions processed by the processing pipeline 4) to physical addresses that identify locations to be accessed in the memory system. The MMU 36 can include at least one translation lookaside buffer (TLB) 38 for caching information defining the address translation mapping depending on page table data obtained from the memory system 34, and can also provide access permissions controlling whether certain regions of the address space are accessible to particular processes executing on the pipeline 4. While the MMU 36 is shown in Figure 1 the load / store unit 28 for data accesses for simplicity, the MMU 36 can also be used to translate addresses and check access permissions for instruction fetch addresses when instructions are fetched for execution by the fetch unit 6.

[0078] Figure 1 The possible processor architecture is just one example, and other examples can haveFigure 1 other components not explicitly mentioned.

[0079] To assist software development, the processor 2 is provided with hardware resources that allow performance analysis information to be collected about the behaviour of instructions processed by the processing pipeline 4, which can be used by software developers to perform code optimisation with the aim of modifying their code to run more efficiently. A sampling circuit 50 is provided to select certain instructions or micro-operations as sample operations to be performance analysed by a performance analysis circuit 52. The sampling circuit 50 can select sample operations at different stages of the pipeline. For example, the sampling circuit 50 can select certain fetch instructions as sample operations and flag those fetch instructions at the fetch stage 6 to mark those instructions as indicating that the performance analysis circuit 52 should collect information about the behaviour of sample operations as the instructions progress down the pipeline 4. Alternatively, the sampling circuit’s flagging of instructions as sample operations can be at the decode stage 8 or later stage. It is also possible to select sample operations at the granularity of individual micro-operations, rather than at the granularity of architectural program instructions fetched from memory.

[0080] The sampling circuit has an interval counter 54 for counting instructions or micro-operations to determine when the next sample operation should be selected. Figure 2 A flowchart showing sampling of operations by the sampling circuit 50 is shown. At step 60, the sampling circuit 50 selects a particular sample interval, which represents the number of instructions or micro-operations to count between two consecutive sample operations. The sample interval can be defined by a user-configurable parameter in a control register or can be fixed to a particular interval. Optionally, the sampling circuit 50 can support a random perturbation function, in which a user-selected set sample interval can be perturbed by a random or pseudo-random value generated by a random number generator or pseudo-random number generator 56. Although Figure 1 A pseudo-random number generator 56 is shown within the sampling circuit 50, but in other examples the sampling circuit can reuse a (pseudo) random number generated by a (pseudo) random number generator set elsewhere in the processing system, which is also used for other purposes other than instruction or micro-operation sampling. For example, the (pseudo) random number generator 56 can generate a random value within a particular range, which is added to (or subtracted from) a sample interval specified as a nominal sample interval to generate the sample interval counted by the interval counter 54 for the next operational cycle. Enabling random perturbation can be useful as it reduces the risk that the same instruction or micro-operation is selected as a sample operation on multiple iterations of a loop when processing the loop. In some implementations, it can be optional whether to enable or disable random perturbation, with a user-configurable control parameter whether random perturbation is enabled.

[0081] Accordingly, in step 60, a sample interval is selected (set to a fixed value, or directly specified by a variable user-configurable parameter, or perturbed randomly or pseudorandomly from fixed / variable interval values), and then at step 62, the interval counter 54 begins counting the number of operations processed by the processing circuit 4. The operations counted can be fetch instructions, decode instructions, or decode micro-operations. Some systems can support only one of these options. Other systems can support the ability of the user to set configuration data that selects which type of operation is counted by the interval counter 54. At step 64, the sample circuit 50 determines whether the interval counter 54 indicates that the sample interval selected at step 60 has elapsed, and if not, the interval counter 54 continues counting operations. The determination of whether the counter has indicated that the sample interval has elapsed can be performed in different ways. For example, the counter can be set to a value corresponding to the selected sample interval at step 60, and then decremented each time one of the counted operations is seen, and can be considered to have elapsed when the counter reaches 0 or overflows beyond 0. Alternatively, the counter can be reset to 0 at step 60 and then incremented or decremented in response to each counted operation at step 62, and is considered to have elapsed when a comparison between the counter and a value corresponding to the sample interval at step 64 indicates that a sufficient number of operations have been counted to reach the sample interval value.

[0082] Regardless of how the elapse of the sample interval is determined, if the sample interval has elapsed, then at step 66, the next operation (e.g., fetch instruction, decode instruction, or decode micro-operation) is marked as a sample operation. For example, a tag bit associated with the instruction can be set, and this tag bit can accompany the instruction or micro-operation selected as the sample operation as it progresses down the pipeline 4. The sample circuit 50 then returns to step 60 to reset the counter 54 again based on a new sample interval (which can be the same as the previously set sample interval if random perturbation is not supported or disabled, or can be different from the previously set sample interval if random perturbation is enabled). By looping Figure 2 , the sample operations continue to be selected at periodic intervals.

[0083] An advantage of selecting only a subset of the operations as sample operations is that this greatly reduces the overhead of tracking information for performance analysis. For example, the sample interval can be set to be long enough that only a single operation in flight within the pipeline 4 is ever selected as a sample operation, so that the performance analysis circuit 52 need only be provided with enough hardware resources to track the behavior of a single sample operation at a time. This avoids the overhead of having to index a storage structure that can store information for multiple operations based on an operation identifier associated with a particular sample operation to select which entry of the storage structure to update based on the information for the particular sample operation.

[0084] However, other implementations can choose to incur greater hardware cost and can choose to support multiple sampling operations selected at a time. In those implementations, sampling as a subset of the operations of a sampling operation still has the advantage of greatly reducing the amount of performance analysis information generated compared to an implementation that would attempt to track every instruction, enabling a wider range of data to be captured for each sampling operation and thus used to perform more meaningful performance analysis.

[0085] Performance analysis circuit 52 includes monitoring circuit 70 for collecting information about the behavior of the sampling operations selected by sampling circuit 50. Although monitoring circuit 70 is shown as a single block within performance analysis circuit 52, in practice, the monitoring circuit can include multiple elements distributed around the processor to collect information from different components of the processor. For example, monitoring circuit 70 can include event detection circuitry to detect the occurrence of various types of events for the sampling operations. The types of events detected can depend on the type of sampling operation. For example, for branch operations selected as sampling operations, events can track whether a branch misprediction occurred or whether branch predictor 18 correctly predicted the branch. For load / store operations, events can include, for example, whether the load / store operation missed in a particular level of cache 30, 32, whether the address translation lookup table for the load / store instruction missed in TLB 38 or in a particular level of TLB, or whether an address fault occurred for the load / store instruction. Other types of events that can be monitored can be instruction fetches that miss in instruction cache 16, such as a fault for an undefined instruction exception, or whether certain instructions were delayed due to contention for resources. Monitoring circuit 70 can also capture information about particular instructions, such as the instruction address for a sampling operation, the target address for a load / store operation, or the branch target address for a branch operation, as well as architectural state items from registers 20 captured at points where the sampling operation reaches particular processing stages (e.g., a context identifier identifying the processing context in which the sampling operation is being processed). For example, monitoring circuit 70 can also have cycle counters that count the number of processing cycles taken to complete certain operations, such as measuring the delay of an address translation or cache lookup table, or the number of cycles for an operation to progress between a first processing point and a second processing point. Thus, it should be understood that monitoring circuit 70 can collect a variety of information.

[0086] The captured monitoring information can be recorded in a sample record, which is stored in the sample record storage circuit 72 (e.g., a register or buffer) of the performance analysis circuit 52. The sample record can be generated using a grouping format as described below. Within the sample record captured for a given sampling operation, the record can specify the operation type associated with the sampling operation (e.g., whether it is a branch, load / store, or ALU operation, etc.) and also provides various information directly attributable to the sampling operation. The capture of the sample record in the sample record storage device 72 is performed in hardware within the context of processing on pipeline 4, therefore no specific software instructions need to be executed to collect the information within the sample record.

[0087] A filtering circuit 74 is provided to allow the performance analysis circuit 52 to select whether sample records captured for a specific sampling operation are accessible for diagnostic analysis. Figure 1 In the illustrated implementation, sample records can be made accessible for diagnostic analysis by writing them to a performance analysis buffer structure 76 stored in memory system 34. The address range allocated for use as the performance analysis buffer 76 can be determined based on buffer address identification information stored in a configuration register 78 of performance analysis circuitry 52, which can be set by the user under software control. Configuration register 78 may also include configuration information specifying what types of information should be included in the sample records for a particular type of sampling operation, and is used to set the filtering criteria used by filtering circuitry 74 to determine whether sample record writing circuitry 79 should write the captured sample records from sample record storage device 72 to performance analysis buffer 76. Writing sample records to performance analysis buffer 76 in memory can be performed without interrupting processing on pipeline 4, thus eliminating the need for specific software instructions to cause the sample records to be stored in memory system. Therefore, a specific number of sample records can be output without any interruption until a sufficient number of sample records have been generated and written. At this point, the performance analysis buffer risks overflowing these sample records, and a performance monitoring interrupt can be triggered, causing processing to be interrupted and allowing the exception handler to then take action to ensure that the sample records previously stored in the performance analysis buffer 76 remain accessible for diagnostic analysis (e.g., by updating the sample records in the configuration register 78 to allow subsequent sample records to be stored in the performance analysis buffer and in a different region of the address space, or by reading the sample records from the performance analysis buffer and storing them elsewhere or outputting them for external analysis). Although Figure 1An example is shown of making sample records accessible for diagnostic analysis by writing them to memory, but an alternative would be to output them to a trace buffer 73, which is a dedicated hardware structure separate from the memory system 34 for storing diagnostic information on-chip, and / or by outputting the captured sample records over a trace output port 75, either directly or via the trace buffer 73, where the trace output port is a set of integrated circuit pins via which sample records can be output to an external off-chip trace analyzer or storage device. Some systems can support this trace output function in place of the ability to write sample records to memory, while others can support both methods and can use configuration information in a register 78 to select which method to use.

[0088] Figure 3 is a flowchart showing performance analysis by the performance analysis circuit 52. At step 80, the performance analysis circuit 52 determines whether a sampling operation is being processed. If not, no monitoring is required. Eventually, once a sampling operation selected by the sampling circuit 50 has been identified, at step 82 the monitoring circuit 70 captures a sample record of the operation type of the specified sampling operation and information about the behavior of the sampling operation directly attributable to the sampling operation. For example, the sample record can also include other information not directly attributable to the sampling operation, such as a snapshot of register state (e.g., the current values of condition code flags used to determine the outcome of conditional instructions, regardless of whether these condition code flag values were directly caused by the sampling operation). The captured sample record is stored in the sample record storage 72. It will be appreciated that step 82 can include multiple separate instances of capturing various pieces of monitoring information at various points of the processing system, which pieces can not be ready at the same time. The sample record in the sample record storage 72 can gradually be composed of multiple pieces of information collected at different points of the pipeline. Alternatively, the monitoring circuit 70 can include some temporary registers that track events and pieces of information as they are detected, and then the events and pieces of information can be used to construct a sample record in a known sample record format ready for output.

[0089] At step 84, the filtering circuit determines whether the sample operation satisfies at least one filtering criterion specified in the configuration registers 78. This filtering criterion can be based on the operation type of the sample operation (e.g., the user can have configured the filter to collect information only about branch operations and not about information about other types of operations if they are selected as sample operations). In addition, the filtering criterion can depend on some of the monitoring information captured by the monitoring circuit 70 and / or information added to the sample record. For example, the filtering criterion can specify that only records associated with mispredicted branches should be allowed to pass through the filter, or that sample records for load / store instructions that miss in the level one data cache 30 should be tracked. The particular set of filtering criteria depends on the user-controlled configuration data in the registers 78 and can include several alternative criteria that are combined in an OR operation to cause sample records that satisfy any one or more of the multiple criteria to proceed beyond the filter, or in a AND operation to cause sample records that satisfy each of two or more criteria to pass through the filter, but sample records that satisfy only one of the criteria to be rejected.

[0090] If the sample operation does not satisfy at least one filtering criterion, then at step 86, the performance analysis circuit 52 allows the captured sample record to be discarded or overwritten without making the sample record available for diagnostic analysis. Thus, it is not necessary to write this sample record to the memory system or output it to the trace buffer 73 or trace output port 75. At the next time a sample operation is processed, then any previously captured information can be overwritten.

[0091] If the sampling operation does indeed satisfy at least one filtering criterion, then at step 88, a determination is made as to which option to enable to make the sample records accessible for diagnostic analysis. If the system has a sample record write circuit 79 and sample record writing to memory is enabled, then at step 90, the performance analysis circuit 52 determines whether the current occupancy of the performance analysis buffer 76 exceeds a set threshold, and if so, at step 92 a performance monitoring interrupt is triggered to interrupt processing on pipeline 4 and invoke execution of an exception handler (in software) which can then take action to avoid performance analysis buffer overflow so that sample record capture can continue. For example, the exception handler can update the performance analysis buffer address parameter to indicate a different address range, allocate additional capacity to the performance analysis buffer 76, or transfer information from the performance analysis buffer 76 to a different storage location to allow continued use of the same performance analysis buffer location. The threshold used at step 90 can be set to match the capacity of the performance analysis buffer, or it can be set to a level below the maximum capacity so that the performance monitoring interrupt can be triggered before an overflow occurs. If the threshold has not been reached at step 90, then at step 94, the sample records captured in the sample record storage 72 can be written out to the performance analysis buffer 76 in memory, and the parameter tracking the current buffer occupancy can be updated to reflect the updated buffer occupancy. The writing at step 94 is triggered by the sample record write circuit 79, while processing continues uninterrupted on pipeline 4.

[0092] On the other hand, if the trace output method is enabled and supported at step 88, then at step 96, the sample records captured in the sample record storage 72 are made available for diagnostic analysis by outputting the sample records to the trace buffer 73 and / or by outputting the sample records to an external device through the trace output port 75 (while processing continues uninterrupted). Some systems can support both the memory write and trace output options and other systems can support only one of these options.

[0093] Figure 4 An example of the packetized format of sample records 100 captured for a given sampling operation is shown. The sample records 100 can comprise a plurality of packets 102, with each packet selected from a set of available packet types that can be used. Each packet can comprise at least a header portion 104 identifying the type of packet, and optionally can also include other information (e.g. there can be many variants of a single type of packet distinguishable by the packet header, or a limited amount of information about the sampling operation itself can be indicated in the header). The header can also specify the size of an associated payload 106 providing monitoring data associated with that packet. Some types of packets can not have a payload 106 and can only include the header 104. For example, packet types can include the following:

[0094] • Header packet: provides header information for the sample record 100 as a whole. For example, the header packet can specify a performance analysis source identifier that identifies the source that captured the sample record. For example, in a multi-processor system there can be multiple processor cores each having performance analysis circuitry 52, and the source ID can distinguish which instance of the processor core handled the operation for which the sample record was captured.

[0095] • Timestamp packet: provides a system timer value that identifies the time at which the sampled operation was processed.

[0096] • Context packet: provides one or more context identifiers that identify the processing context in which the sampled operation was processed. For example, the context identifiers can include an address space identifier that distinguishes processes associated with different virtual address spaces and / or a virtual machine identifier that identifies a virtual machine in which the sampled operation was processed.

[0097] • Event packet: provides a summary of one or more events that occurred for the sampled operation. For example, the event packet can provide an event mask that includes multiple bits, with each bit indicating whether a corresponding type of event occurred. The header portion 104 of the event packet can distinguish multiple alternative types of event masks that are used to indicate different sets of event types. This avoids the need to encode event masks for sets of event types in which no events occurred.

[0098] • Counter packet: provides at least one counter value that indicates a delay associated with a particular action taken for the sampled operation. For example, the delay can be associated with a memory access operation or an address translation. The delay can also indicate a number of cycles between the sampled operation reaching a given point in the pipeline and reaching a given later point in the pipeline.

[0099] • Operation type: a packet that indicates the type of operation that was sampled. For example, the operation type can distinguish between a load / store operation, a branch operation, or an ALU operation.

[0100] • Address packet: indicates an address associated with the sampled operation.

[0101] • End marker packet: indicates the end of the current sample record 100, so that any subsequent packets will be interpreted as part of the next sample record. The use of an end marker packet 102 can be used to support a sample record format that has a variable size, so that a variable number of packets can be included, depending on how much information of interest is to be recorded. However, other approaches can have a fixed format for sample records of some known size (or can fix the size of sample records for a given type of sampled operation, which can be different from the fixed size for other types of sampled operations). If a fixed size record format is used, then the end marker 102 can not be needed.

[0102] • Imputation Groups: Used to fill in the remaining portion of a fixed-size sample record if a fixed-size format is used. Imputation groups have no payload.

[0103] The specific encoding used in header section 104 to identify which type of packet is being represented is arbitrary and can be selected based on the needs of a particular system. Some packet types support headers that can be variable-sized, allowing for the provision of prefix headers to offer additional information beyond the normal header. This includes the prefix being optional, allowing the same header to be included with or without the prefix. In some cases, the header can specify the size of payload 106, making variable-sized payloads possible. The number of packets included in a sample record for a given type of sampling operation can vary; for example, some records may require a larger number of events, counters, or addresses compared to other records.

[0104] Figure 5 An example of a sample record 100 for a payload instruction (selected as any example) is shown. The portion with underlined text represents the packet header 104, and the portion without underlined text represents the packet payload 106. It should be understood that the specific content of the sample record depends on what happens when the sampling operation is processed in this way, and therefore can vary significantly. Figure 5 In a specific example, the sample record includes a header group providing the source ID, a timestamp group providing the system timer value, two address groups (the first address group provides the program counter address identifying the instruction address of the load instruction itself, and the second address group identifies the data address indicating the target address from which the load will be executed), and two context groups specifying the address space identifier (CONTEXTIDR_EL1) and the virtual machine identifier (CONTEXTIDR_EL2), respectively; an operation type group, which in this example includes a prefix header indicating the size of the data access associated with the load operation, wherein the main operation type header indicates that the sampling operation is a load (not a branch or ALU operation). The sample record also includes two counter groups providing delay count values, in this example a first count value indicating the delay between the address issuing the sampling operation and the address generating the load operation, and a second count value indicating the delay between the generated address and the load data returned from the memory system. The sample record also includes an event group providing a mask indicating one or more events occurring for the load (such as cache hit / miss, address translation hit / miss in TLB 38, etc.). Finally, the sample record includes an end marker group. Therefore, the sample record 100 provides detailed information about the results of the sampling operation, the time spent processing the operation, and other information about when and in what context the operation was processed, all of which can be useful for software developers to diagnose potential problems with their code.

[0105] Figure 6 An example of an address packet 102 is shown in more detail. For an address packet, the address type header 104 has a value that indicates that the packet is an address packet (distinguishing from other types of packets), but also identifies a particular type of address represented in the payload (selected from one of a number of different types of addresses). For example, the address in the payload can be identified as one of: an instruction virtual address identifying an address of an instruction associated with the sample operation itself, a data access virtual address identifying a target address of a data access, a branch target address identifying an address to which a branch should lead if taken, or a reference instruction address marking a reference instruction for which execution sequentially proceeds between any two of the intermediate instructions positioned in program order between the reference instruction and a given instruction corresponding to the sample operation (without taking a branch).

[0106] The use of reference instruction address packets is further discussed below with respect to Figure 7 an example sequence of instructions shown in Figure 7 In this example, the taken branch instruction 200 causes the block of instructions 202, 204, etc. to be processed, including several not-taken branch instructions 208, 216, before a further taken branch is taken at instruction 218. In this example, the taken branch instruction 218 represents a function call to function code at instructions 230-240, where the function code terminates with a return branch 240 that is taken to return to instruction 220 just after the previous taken branch 218. Except for the taken branch instructions 200, 218, 240, all other branch instructions are not taken in this example. The taken branch instructions represent points of non-sequential program flow. Between any two taken branches, the intermediate instructions are executed sequentially (meaning that no branches are taken between these instructions - as in an out-of-order processor, the intermediate instructions can be executed in an order that differs from program order (if instruction 210 is not executed in order before instruction 206, this would not be considered a change in non-sequential program flow)).

[0107] In this example, assume that the taken branch instruction 218 is selected by the sample circuit 50 as a sample operation, and thus the performance analysis circuit 52 captures a sample record of the taken branch 218. The sample record of the taken branch 218 can include a reference instruction address packet as described above to identify an address of a reference instruction that is an earlier or later instruction than the taken branch for which the control flow (excluding any non-sequential changes in program flow associated with the taken branch itself) is sequential in a sequence of intermediate instructions between the sample operation 218 and the reference instruction. As in the example of Figure 7As can be seen, if branch 218 is sampled as a sample operation, the reference instruction can be any of instructions 202-217 prior to taking branch 218 or any of instructions 230-240 after taking branch 218 (which do not encounter any intermediate out-of-order changes in program flow beyond the change triggered by branch 218 itself). However, instructions 200 or instructions 220-224 cannot be indicated as reference instructions by the reference instruction address grouping because there is already an intermediate out-of-order change in program flow.

[0108] The reference instruction address grouping can be used to enable the sample records captured by performance analysis circuit 52 to be used to assist in profile-guided optimization (PGO) of program code. PGO is a technique used by programmers to use performance analysis to improve program runtime performance. PGO recognizes that some parts of program code are executed more frequently than others, and thus it can be most efficient to focus any development efforts on optimizing the performance of the more frequently executed code parts over the less frequently executed parts. Even without the ability of sample record tracking reference instruction addresses, the sample records captured by performance analysis circuit 52 based on systematic sampling instructions or micro-operations selected by sampling circuit 50 can be used to assist in PGO. For example, after performance analysis is complete, performance analysis buffer 76 can contain records of sample operations that passed through the filters set by filtering circuit 74, and sample records associated with any type of instruction can specify the instruction address (program counter or PC) associated with the sample operation. This can be used to generate a basic profile of the program, such as a hot spot profile indicating the relative frequency of execution of different instructions. Programmers or compilers can use the profile to guide them on the areas of code to focus on for performance improvement.

[0109] However, a problem with systematic sampling of operations for performance analysis is that a large portion of the operations performed by the processing circuit are not tracked by the sample records written to performance analysis buffer 76. From a single sample record, based on the PC address of each sample operation, it is only possible to deduce the execution of one particular instruction, not any earlier instructions (as the sample operation can have been a branch target for some unknown branch). Thus, if each sample record only provides evidence of the execution of a single instruction, this means that in order to collect enough information for the collected samples to be sufficient to obtain a statistically valid view of the relative execution frequency of different parts of code, a very large number of samples can be required, which can not be practical given the required data rate and storage overhead.

[0110] In contrast, other types of diagnostic monitoring techniques can support capture of a more limited set of information for each instruction. For example, for comparison, consider a trace solution in which storage elements are provided to record the last 16 taken branches, with each branch record storing two addresses: the instruction address of the taken branch and the branch target address of the taken branch. Each time a taken branch is encountered, then the oldest record is discarded and the record of the most recently taken branch is allocated to the storage element. An interrupt is generated at intervals of a particular number of instructions (e.g., every 1,000,000 instructions) to cause the last 16 taken branch records to be sampled and written out to memory or output through a trace port. If the instructions are executed at 1,000,000,000 instructions per second, then this would generate approximately 1000 samples per second (and thus 1000 interrupts per second). On average, it is common that approximately 1 in 10 instructions can be taken branches, so 16 taken branches can span approximately 150 instructions (it should be noted that the number of instructions represented by 16 branches is not 160, as the "fence-post" nature of the branch records - 15 blocks of 10 instructions each would be defined by 16 taken branches). Thus, the last 16 taken branch records give evidence of approximately 150 instructions being executed, which can be used to develop a hot-spot profile for PGO as described above. 1000 samples per second means that the profile can be based on approximately 150,000 instructions per second. If each branch record is 16 bytes of data (e.g., two 64-bit addresses), then each sample would be 256 bytes, which means that approximately 250KB / s of data is collected. However, a problem with such a simple trace solution is that this sampling only captures the instruction address and branch target address of taken branch instructions and does not provide any other diagnostic information.

[0111] Returning instead to the discussion Figure 1The method described in the embodiments based on statistical sampling, which has the advantage that many other types of information can also be logged. However, this is at the cost of generating a much larger sample record. In order to be able to match a tracing method that is capable of counting 150,000 instructions per second to be helpful for hotspot performance analysis, this would require the sampling circuit 50 to use a sampling rate of about 1 in every 6700 instructions. Assuming that each sample record comprises 64 bytes (for example, using a fixed size format that can be simplified for hardware implementation by using the padding grouping described above) and that a 64KB buffer 76 is allocated in memory thus 1024 samples can be held, this means that the interrupt rate is greatly reduced to about 145 samples (interrupts) per second compared to the tracing example, as only an interrupt needs to be generated once the 64KB buffer has filled, rather than at every sample (as in the tracing solution described above). However, with respect to the statistical performance analysis solution, the data rate is greatly increased to 9MB per second, almost about 40 times higher than the tracing solution. The reason for this increased data rate is that a much larger set of information is collected for each sample, and while statistical sample based performance analysis is generally expected to operate at a relatively low sampling rate, in order to be able to match the number of samples required to give a reasonable PGO hotspot profile, the sampling rate would need to be increased. Thus, based on just capturing the PC of each sampled operation, it can be difficult to use sample based performance analysis techniques to assist PGO.

[0112] However, by providing the ability to include within the sample record of a sampled operation a form of address grouping that can encode an address provided as a reference instruction address that marks a point in program order that is earlier or later than the PC of the sampled operation that is sequential with the intermediate processing, this means that each sample record can now provide evidence not only of the execution of the current sampled operation, but also of a specific number of other instructions that were executed (without the need to include additional sample records for those other instructions). By increasing the number of instructions that can be deduced from each sample record that were executed, this reduces the number of sampled operations that are required by the tracing to profile the execution of a specific number of instructions for a hotspot profile. This can greatly reduce the data rate required.

[0113] Again, continuing the previous numerical example, if such additional reference instruction address indicators are included only in samples taken for a taken branch and indicate the branch target address of the most recent taken branch, and filter 24 is configured to allow only taken branch sample records to be written to performance analysis buffer 76, then assuming the sampling rate is still 1 instruction in every 6700 instructions, filter 74 will discard approximately 90% of the sampling operations (assuming approximately 1 in 10 operations is a taken branch), but now each sample record gives evidence of (on average) 10 instructions being executed including the sampled instruction. Thus, 10 times fewer sample records are needed to reach the approximately 150,000 instructions for hot spot profile counting in order to compete with the above-described trace solution. If each sample record is still 64 bytes as described above, this approach reduces the data rate to 930 KB per second, which is 10 times less than the sample-based performance analysis using only PC addresses, and much closer to the above-described trace solution. However, unlike the trace solution, each sample record also provides a much larger range of information about the processing operations, including cycle counts, even encoding, etc. Thus, this approach enables other types of performance analysis to be performed using the same set of sample records as used for PGO performance analysis, which would not be possible with the trace solution. Thus, software development can be more efficient.

[0114] Filter circuit 74 can support different options for selecting which sample records are available to the developer for diagnostic analysis, and can support one option where the filter can select only sample records of taken branch instructions, and another filter setting where both taken and not-taken branches have their sample records passed by the filter. It can be assumed that in order to obtain the maximum amount of information for each sample about the frequency of execution of nearby instructions in program order, it can be desirable for a given sampling operation to track the location of the most recently taken branch or the next taken branch in program order, as this can maximize the range of intervening instructions that can be inferred to have been executed. However, it has been observed through experimentation that if the filter allows both taken and not-taken branches to output their sample records for analysis, and both taken and not-taken samples include reference instruction address indicators, this can result in a statistical bias in the hot spot profiles determined based on the captured reference instruction address indicators. The reason is as follows.

[0115] Consider Figure 7an example where, for the sake of argument, the intermediate branches 208, 216 between taken branch 200 and taken branch 218 have consistent behavior such that they are never taken (e.g., branches 208, 216 can test for rare error conditions that do not occur in the current execution run), and there are no other branches in the middle of the sequence 202-218 such that every time this code is executed, the code is reached after the branch from instruction 200 to load instruction 202. Since branches 208 and 216 are never taken, then this would mean that the entirety of instructions 202 to 218 would have been executed an equal number of times, so any hot spot profile should indicate an equal execution count for the entire sequence of instructions 202 to 218.

[0116] If filter 74 only passes taken branch sample records, but discards not-taken branch sample records, and the reference instruction address indicator is included in the taken branch sample records to indicate the branch target address of the most recent taken branch, then as shown in Figure 8 the sample record for taken branch instruction 218 can indicate the address of instruction 202, which is the branch target of the most recent taken branch 200. Similarly, if taken branch 240 has been selected for sampling, then its sample record would have indicated the reference instruction address indicator, which indicates the instruction 230 at the branch target address of the most recent taken branch 218. When filter 74 only allows taken branch sample records to be output, this approach would be acceptable because every time taken branch 218 is sampled, the entirety of instructions 202-218 would be inferred to have been executed, so the hot spot profile would provide a fair representation of the relative frequencies by which one of the blocks 202-218 is executed compared to another of the blocks 202-218.

[0117] However, if the filter 74 is instead set to allow sample records of both taken and not-taken branches to be output for diagnostic analysis (and both taken and not-taken samples record the branch target of the most recent taken branch), then this would mean that the sample record would specify the same address representing the branch target 202 of the most recent taken branch, regardless of whether the sample operation was selected as the branch 218 or the earlier not-taken branch 216. Thus, if the not-taken branch 216 was sampled, the hot spot profile would deduce that instructions 202-216 were executed, but if the taken branch 218 was sampled, the hot spot profile would deduce that instructions 202-217 were executed. This means that while instructions 202-216 are deduced to have been executed regardless of whether the sample selected the branch 216 or the branch 218, instruction 217 is only deduced to have been executed when the taken branch 218 is sampled and not when the not-taken branch 216 is sampled. This means that instruction 217 can end up with a lower execution count in the hot spot profile, even though in reality, instruction 217 is executed as frequently as instructions 202-216 because of the overall not-taken branch 216. Thus, sampling both taken and not-taken branches for the reference instruction address indication, but using the reference instruction address indication to refer only to the earlier taken branch, risks generating a biased profile.

[0118] This bias can be avoided by ensuring that the population of operation types used to generate the reference instruction address indicator matches the population of operation types used as the basis for the hot spot profile. This can be achieved by providing the performance analysis circuit 52 with the ability to support a reference instruction address indicator indicating the instruction to which program flow is directed after the most recent branch, regardless of whether that branch was taken and regardless of whether the most recent branch was itself sampled. Thus, as shown in Figure 2, the reference instruction address grouping for the taken branch 218 can indicate the ADD instruction 217 as the reference instruction, which is the next instruction after the most recent not-taken branch 216 in program order. By contrast, if the not-taken branch 216 has been sampled, its sample record would have indicated the address of the ADD instruction 210 after the previous not-taken branch 210 in the reference instruction address grouping. If the not-taken branch 208 has been sampled, its sample record would indicate the address of the LD instruction 202, which is the instruction to which program flow is directed after the most recent branch 200 in program order - because the taken branch 200 was sampled, the reference instruction is then the instruction at the branch target address of the taken branch, rather than the instruction at the next sequential address of the not-taken branch. This approach means that if the branch immediately following is sampled, then only one of the instructions will be deduced to have been executed, which avoids the "double counting" of some instructions of multiple different taken branches, which can be considered to inflate the execution count of some instructions compared to others. Figure 9

[0119] Figure 8 and​Figure 9 And the above example describes an implementation in which the reference instruction address tracks the address of the next instruction after a taken branch or a previous branch. As Figure 10 and Figure 11 An alternative approach would be to use the monitoring circuit 70 to track a reference instruction that is later in program order than the sampled operation.

[0120] As Figure 10 indicated, if a not-taken branch is not to be used as a reference instruction, then the reference instruction address indicator can indicate the address of the next taken branch after the sampled taken branch. For example, if the taken branch 218 in Figure 7 is sampled, then the sample record for the branch 218 can indicate the address of the next taken branch 240 in the reference instruction address packet.

[0121] Alternatively, to avoid the bias problem described above, if both taken branches and not-taken branches are to be used as reference instructions, then the reference instruction address should point to the address of the next branch in program order after the sampled operation (whether or not that branch is taken, and whether or not that branch is itself sampled), and so as Figure 11 indicated, for the example of Figure 7 the sample record for the operation 218 can indicate the address of the next not-taken branch instruction 234.

[0122] Whether or not a not-taken branch is to be used as a reference instruction can depend on configuration information in the configuration registers 78 of the performance analysis circuit 52, which can be programmed by software executing on the processing pipeline 4 and / or by an external debug unit providing debug control signals via the debug / tracing port 75. In one example, the filter settings of the filtering circuit 74 can control whether or not a not-taken branch is to be used as a reference instruction - if the filter allows a not-taken branch sample record (including a reference instruction address indicator) to be output, then the not-taken branch can be considered a reference instruction, but if the filter prevents a not-taken branch sample record from being output for diagnostic analysis, then there is no need to consider the not-taken branch as a reference instruction.

[0123] However, in another example, the configuration register 78 can contain controls for defining what types of instructions can be used as reference instructions, along with the controls for the filter 74, and can leave it to the software to create sensible combinations according to the type of analysis being performed. For example, although an out-of-alignment combination of filter settings and reference instruction definitions can create a bias as discussed above, it can not be a problem to output sample records according to such a mismatched combination, provided that the analysis software performing the performance analysis is aware of when to generate profiles to ignore the unreliable information. For example, the software can wish to disable the filter 74 entirely, so that the full range of operations is sampled, since each sample contains performance analysis information (events, delays, etc.) that would be discarded by the filter. To create a non-biased hot spot profile, the software can be aware so as to only pick the reference instruction address grouping output in sample records that take a branch, even though the output sample records also include sample records that do not take a branch for other purposes. Thus, the software can want to control the reference address criteria and the filter criteria independently. To provide an architecture of the processing apparatus 2 that enables the software to obtain a non-biased profile, it can be sufficient to ensure that the support is present to enable the performance analysis circuit 52 to process a non-branching instruction as a reference instruction if this is desired by the software, but that this functionality must always be used or required for any particular filter setting set.

[0124] In Figures 7 to 11 In the example of the present application, the reference instruction address grouping is included only for branch instructions and is not included for other types of sampling operations, if selected. Whether other operations would also track a reference instruction address is optional if selected as a sampling operation.

[0125] Figure 12 and Figure 13 A flowchart showing a method for setting the reference instruction address of a sample record in an example in which the reference instruction is either the given instruction itself if the given instruction immediately follows a most recent taken branch or not-taken branch, or is an instruction earlier in program order than the given instruction is shown. With this method, the monitoring circuit 70 can include a storage element to store a tracking instruction indicator for setting the reference instruction address indicator of a sample record captured for a sampling operation. Various types of reset events cause the tracking instruction indicator to be updated, and then when a subsequent sampling operation occurs, the reference instruction address indicator can be set based on the tracking instruction indicator.

[0126] Figure 12The maintenance of the trace instruction indicator is shown. At step 300, the monitoring circuit 70 determines whether a taken branch has been processed by the execution stage 12 and, if so, at step 302, the trace instruction indicator is reset and indicated as valid. The trace instruction indicator can be represented in different ways. In one example, the trace instruction indicator can directly identify an address. In this case, at step 302, the trace instruction indicator can be set to the address of the instruction following the taken branch (i.e. the branch target address of the taken branch). However, another approach can be for the trace instruction indicator to act as a counter to count the number of instructions processed since the point at which the trace instruction indicator was reset. In such an embodiment, at step 302, the trace instruction indicator can be reset to zero. As subsequent instructions are processed, the counter can then be incremented in response to each subsequently processed instruction.

[0127] If no taken branch is encountered, then at step 304, it is determined whether a not-taken branch is processed and whether the not-taken branch is used as a reference instruction (e.g. this can be when (a) the filtering criteria applied by the filtering circuit 74 specifies that not-taken sampled records are allowed to be used for diagnostic analysis, and (b) the not-taken sampled record specifies a reference instruction address indicator). If so, at step 302, the various instruction indicators are reset and are valid, either by setting the trace instruction indicator to indicate the address of the next instruction in program order following the not-taken branch, or by resetting the counter to zero as described above. This ensures that the most recent branch that was not a taken branch sampled taken / not-taken operation will have its reference instruction address indicator indicating the instruction following the most recent not-taken branch, rather than the branch target address of the most recent taken branch, to avoid the skew problem described above.

[0128] Otherwise, at step 308, it is determined whether the profile has been newly enabled following a previous execution period in which performance analysis was disabled. Sometimes a developer can not be interested in collecting sample records for the entire program, but can wish to focus on a particular section. Accordingly, the performance analysis circuit 52 can support the ability to enable or disable performance analysis at particular preconfigured instruction addresses based on user configured information in the configuration registers 78. When performance analysis is newly enabled, then any information in the trace instruction indicator can be unreliable and so at this point, at step 302, the trace instruction indicator can be reset, e.g. by updating the trace instruction indicator to indicate the address of the instruction representing the point at which performance analysis was enabled, or resetting the counter to zero.

[0129] At step 310, the monitoring circuitry can determine whether an exception has occurred, and if so, proceed to step 302 to reset the trace instruction indicator, for example, by setting the instruction address to indicate the address of the instruction at the point where the exception occurred, or by resetting a counter to zero. Similarly, if an exception return occurs at step 312, the trace instruction indicator can be reset at step 302, for example, by setting the instruction address to indicate the exception return address (the address of the instruction handling the exception return). This prevents the trace instruction indicator from being skewed by operations performed during exception handling that do not indicate an interruption of the program performing performance analysis.

[0130] It should be understood that not all types of events examined in steps 300 to 312 are applicable to a given implementation, and some implementations may examine only a subset of these events. Furthermore, although Figure 12 A series of sequential checks are shown in a specific order, but it should be understood that other implementations may perform these checks in a different order or may perform multiple checks in parallel.

[0131] exist Figure 12 In the example, at step 302, the tracking instruction indicator is reset, but it remains valid. As shown by the dashed line, an alternative could be to invalidate the tracking instruction indicator at step 306 if one of the events detected at steps 308, 310, or 312 occurs. If the tracking instruction indicator is invalid during the sampling operation, the sample record may omit the reference instruction address indicator or include an indication that the reference instruction address indicator is invalid.

[0132] As mentioned above, in some specific implementations, the processing of the sampling operation itself may also cause the tracking instruction indicator to be reset or invalidated.

[0133] Figure 13is a flowchart showing how the trace instruction indicator can be used to set the reference instruction address indicator for a sample record. At step 320, the performance analysis circuit 52 checks whether a sampling operation is being processed. When a sampling operation is detected, then the monitoring circuit 70 collects information about the behaviour of the sampling operation. At step 322, it is determined whether the inclusion of the reference instruction address indicator is supported and enabled for the particular operation type represented by the sampling operation. For all types of sampling operation, the inclusion of the reference instruction address indicator can not be supported. For example, in some examples the reference instruction address indicator can only be included in sample records for branch operations, or only for taken branches and not for not-taken branches (depending on the implementation choice). Even in those operation types for which the inclusion of the reference instruction address indicator is supported, the configuration registers 78 can specify configuration data indicating whether the inclusion of the reference instruction address indicator is enabled or disabled. Thus, if the current operation for which the sample operation is selected is not a type for which the reference instruction address indicator is supported, or the configuration data indicates that the reference instruction address indicator should not be included, then at step 324 the reference instruction address indicator is omitted from the sample record.

[0134] If the reference instruction address indicator is to be included in the sample record for the current sampling operation, then at step 326 the performance analysis circuit 52 determines whether the trace instruction indicator, which is maintained as described in Figure 12

[0135] If the trace instruction indicator is valid, then at step 328 the valid reference instruction address indicator is included in the sample record for the sampling operation, with the value of the reference instruction address indicator being set based on the trace instruction indicator. The particular format of the reference instruction address indicator can vary. If the trace instruction indicator indicates the address of a particular instruction, then this can be output explicitly as the reference instruction address indicator, similar to the above described Figures 8 to 11 ​The alternative can be to compress the sample record by indicating the reference instruction address indicator as a relative address calculated with respect to the instruction address (PC) of the instruction associated with the sampling operation itself. The difference between the reference address set in the trace instruction indicator and the current program counter address associated with the sampling operation can be determined and encoded as the reference instruction address indicator. Another option is that if the trace instruction indicator is an instruction count as discussed above, counting the number of instructions processed since the counter was reset, the reference instruction address indicator can be set equal to the instruction count represented by the trace instruction indicator. Regardless of the particular form taken, the reference instruction address indicator provides information that enables determination of the location of an earlier instruction in the program order for which the execution of the intermediate instruction is sequential.

[0136] Figure 14 An alternative approach to tracking the reference address is shown in embodiments in which the reference instruction indicated by the reference address can be a certain instruction that is later in the program order than the sampling operation. For example, the reference instruction can be the instruction at which one of the following occurs after the sampling operation: a taken or not taken branch, or one of the reset events discussed above (enablement of performance analysis, taken exception, exception return). With this approach, there is no need to maintain a trace instruction indicator that is reset each time a branch is encountered. Rather, the monitoring circuit 70 can wait for the sampling operation to be detected and then monitor for the next relevant event to set the reference address indicator.

[0137] Thus, at step 350, the monitoring circuit 70 detects whether a sampling operation has been identified, and if not, waits for the next sampling operation to be identified by the sampling circuit 52. Once a sampling operation is identified, at step 352 it is determined whether the inclusion of a reference instruction address indicator in the sample record is supported and enabled for the type of operation corresponding to the sampling operation (as discussed above at step 322 of Figure 3). If the inclusion of the reference instruction address indicator is not supported or is currently disabled for the current sampling operation, the method returns to step 350 to wait for a later sampling operation. It will be appreciated that in this case other information can still be included in the sample record for the sampling operation. Figure 13

[0138] ​If the inclusion of a reference instruction address indicator is supported and enabled for the current operation type that is detected as a sample operation, at step 354 the monitoring circuit 70 monitors for a next occurrence of any of the following: a branch taken; a branch not taken (if the configuration information 78 specifies that a branch not taken should be used as a reference instruction); an enabling of performance analysis after a previous period when performance analysis was disabled; an exception taken; or an exception return event (and in some implementations, the processing of another sample operation, although in practice it is relatively unlikely that an event of the other type will occur before the next sample operation is detected). If any of these events occurs, at step 356 it is determined whether the next occurrence is a branch, and if so, at step 358 an effective reference instruction address indicator is included in the sample record of sample operation indication information. For example, the indicated reference instruction address can indicate the instruction address of the branch taken as an absolute value or as a relative value relative to the address of the instruction associated with the sample operation, or the indicated reference instruction address can indicate a count of the number of instructions between the sample operation and the branch taken (if a counter is used, the counter can be reset at step 350 when the sample operation is detected).

[0139] If the event that occurs from the list shown at step 354 is an event other than a branch, at step 360 a reference instruction address indicator can be included in the sample record that indicates the reference address of the reference instruction associated with the event that occurred. The reference address can be indicated as an absolute value, a relative value, or as a count of the number of instructions between the sample operation instruction and the instruction at the point associated with the event detected at step 354. The reference address can be the address of the instruction that represents the point at which performance analysis was enabled or an exception was taken, or can correspond to an exception return address. Alternatively, instead of indicating an effective reference instruction address indicator, at step 360 the reference instruction address indicator can be omitted from the sample record or indicated as invalid.

[0140] While the exemplary embodiments of the application have been described in detail hereinabove, it is to be understood that the application is not limited to the precise embodiments described, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the application as defined by the appended claims.

Claims

1. A data processing apparatus, comprising: A processing circuit that performs data processing operations in response to instructions fetched from a cache or memory or micro-operations decoded from the instructions; A sampling circuit that selects a subset of instructions or micro-operations as the sampling operations to be performed for performance analysis; as well as Performance analysis circuitry, in response to processing of an instruction or micro-operation selected by the sampling circuit as a sampling operation, captures sample records specifying the operation type of the sampling operation and information about the behavior of the sampling operation directly attributable to the sampling operation; wherein: The performance analysis circuit is capable of including a reference instruction address indicator in the sample record captured for a sampling operation corresponding to a given instruction, indicating the address of a reference instruction that appears earlier or later than the given instruction in the program sequence, and the control flow is sequential between the reference instruction and any instructions occurring between the given instruction and the reference instruction in the program sequence. The sampling circuit is configured to select the next sampling operation in response to the elapsed sampling interval counted by the interval counter.

2. The apparatus of claim 1, wherein the performance analysis circuit is capable of setting the reference instruction address indicator to indicate the address of an earlier instruction that appears earlier than the given instruction in the program sequence, the control flow being sequential from the earlier instruction to the given instruction.

3. The apparatus according to any one of claims 1 and 2, wherein the performance analysis circuit is capable of setting the reference instruction address indicator to indicate the address of a later instruction that appears later than the given instruction in the program sequence, and the control flow is sequential from the next instruction after the given instruction to the later instruction.

4. The apparatus according to any one of claims 1 and 2, wherein the performance analysis circuit is capable of setting the reference instruction address indicator to indicate the branch target address of the most recent branch instruction taken before the given instruction or the instruction address of the next branch instruction taken after the given instruction.

5. The apparatus according to any one of claims 1 and 2, wherein the performance analysis circuit is capable of setting the reference instruction address indicator to indicate an instruction address of one of the following: The instruction that directs program flow to after the most recent branch instruction preceding the given instruction, regardless of whether the most recent branch instruction is taken or not; or The instruction address of the next branch instruction following the given instruction, regardless of whether the next branch instruction is taken or not.

6. The apparatus according to any one of claims 1 and 2, wherein the performance analysis circuit is capable of setting the reference instruction address indicator to indicate the address of an instruction other than any of the following: The instruction at the branch target address of the most recently taken branch instruction preceding the given instruction; and The address of the instruction that will take a branch instruction after the given instruction.

7. The apparatus of any one of claims 1 and 2, wherein the performance analysis circuit is configured to set the address associated with the most recent instruction address reset event preceding the given instruction or the next instruction address reset event following the given instruction to the address indicated by the reference instruction address indicator of the given instruction; and The performance analysis circuit is configured to detect the branching operation as a reference instruction address reset event.

8. The apparatus of claim 7, wherein the performance analysis circuit is also configured to detect a process that does not perform a branch operation as the reference instruction address reset event.

9. The apparatus of claim 8, wherein the performance analysis circuit is configured to determine, based on configuration information configurable by software or by an external device, whether the process of not performing a branch operation should be detected as the instruction address reset event.

10. The apparatus of claim 7, wherein the performance analysis circuit is further configured to detect one or more of the following as the reference instruction address reset event: Enabling of performance analysis performed by the performance analysis circuit after performance analysis was previously disabled; Take abnormal actions; Return from an exception; as well as Processing of the sampling operation selected by the sampling circuit.

11. The apparatus of claim 7, wherein when a reference instruction address invalidation event occurs between the most recent instruction address reset event and the given instruction, or between the given instruction and the next instruction address reset event, the performance analysis circuit is configured to omit the reference instruction address indicator from the sample record or indicate in the sample record that the reference instruction address indicator is invalid.

12. The apparatus of claim 11, wherein the invalid reference instruction address event includes one of the following: Processing of the sampling operation selected by the sampling circuit; Enabling of performance analysis performed by the performance analysis circuit after performance analysis was previously disabled; Take abnormal actions; as well as Return from an exception.

13. The apparatus of any one of claims 1 and 2, wherein at least when the given instruction is a branch instruction to take or not take, the performance analysis circuit is capable of including the reference instruction address indicator in the sample record captured for the sampling operation corresponding to the given instruction.

14. The apparatus of any one of claims 1 and 2, wherein the performance analysis circuit is configured to omit the reference instruction address indicator from the sample record when the performance analysis configuration information specifies that the capture of the reference instruction address indicator is disabled.

15. The apparatus according to any one of claims 1 and 2, wherein the sample record comprises one or more groups; The performance analysis circuit is configured to include the reference instruction address indicator in an address group for specifying the address associated with the sampling operation, the address group including a group header specifying an address type indicator for identifying the address type associated with the sampling operation; The address type indicator has several valid codes, including: The address group indicates the reference instruction address code that specifies the reference instruction address indicator; as well as The address group indicates at least one other encoding of the address besides the reference instruction address indicator.

16. The apparatus according to any one of claims 1 and 2, comprising a sample record writing circuit for writing the sample record captured by the performance analysis circuit into a memory.

17. The apparatus of claim 16, wherein the sample record writing circuit is configured to write the sample record captured by the performance analysis circuit into a memory while the processing circuit continues uninterrupted processing.

18. The apparatus of claim 16, further comprising a filtering circuit that determines whether the sample record writing circuit should write the sample record captured by the performance analysis circuit for the sampling operation into memory based on whether the sampling operation meets at least one filtering criterion.

19. The apparatus of claim 18, wherein the filtering circuit is configurable to specify a criterion for whether the sampling operation corresponding to the sample record is a branching operation as one of the at least one filtering criteria.

20. The apparatus of claim 18, wherein the filtering circuit is configurable to specify a criterion for not performing a branching operation corresponding to the sampling operation of the sample record as one of the at least one filtering criteria.

21. The apparatus of claim 1, wherein when random perturbation of the sampling interval is enabled, the performance analysis circuit is configured to apply random or pseudo-random perturbation to the sampling interval counted by the interval counter.

22. The apparatus according to any one of claims 1 and 2, wherein the reference instruction address indicator designates one of the following: The absolute value of the address of the reference instruction; The relative offset of the address of one of the given instruction and the reference instruction relative to the address of the other of the given instruction and the reference instruction; and The number of instructions between the given instruction and the reference instruction.

23. A data processing method, comprising: Data processing operations are performed in response to instructions fetched from a cache or memory, or micro-operations decoded from said instructions; A subset of instructions or micro-operations is selected as the sampling operations to be analyzed, wherein the next sampling operation is selected in response to the elapsed sampling interval counted by the interval counter. as well as In response to a processing instruction or micro-operation selected as a sampling operation, a sample record specifying the operation type of the sampling operation and information about the behavior of the sampling operation directly attributable to the sampling operation are captured; wherein: The sample record captured for a sampling operation corresponding to a given instruction includes a reference instruction address indicator that indicates the address of a reference instruction that appears earlier or later than the given instruction in the program sequence, and the control flow is sequential between the reference instruction and any instructions that occur between the given instruction and the reference instruction in the program sequence.

Images