Instruction block-based performance monitoring

Abstract

The present application discloses instruction block-based performance monitoring. Techniques for block-based performance monitoring are described. In an embodiment, an apparatus includes: execution hardware for executing a plurality of instructions; and block-based sampling hardware. The block-based sampling hardware is used to: identify an instruction block based on a first branch instruction in the plurality of instructions and a second branch instruction in the plurality of instructions; and to collect performance information during execution of the instruction block.

Description

Background Art

[0001] On computers and other information processing systems, various techniques may be used to collect data for use in analyzing the performance of hardware and software. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various examples according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0003] Figure 1A A telemetry system according to an embodiment is illustrated.

[0004] Figure 1B Illustrated is a processor core supporting block-based performance monitoring according to an embodiment.

[0005] Figure 2A Figure 1 illustrates an instruction-based sampling approach.

[0006] Figure 2B A block-based sampling method according to an embodiment is illustrated.

[0007] Figure 3A Diagram of the stack frame when a calling procedure calls another procedure.

[0008] Figure 3B A value profiling method according to an embodiment is illustrated.

[0009] Figure 4 An example computing system is illustrated.

[0010] Figure 5 A block diagram illustrating an example processor and / or System on a Chip (SoC) that may have one or more cores and an integrated memory controller.

[0011] Fig. 6A is a block diagram illustrating both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to an example.

[0012] Figure 6B is a block diagram illustrating both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor according to an example.

[0013] Figure 7 An example of execution unit(s) circuitry is shown.

[0014] Figure 8 is a block diagram illustrating converting binary instructions in a source instruction set architecture to binary instructions in a target instruction set architecture using a software instruction converter according to an example. DETAILED DESCRIPTION

[0015] The present disclosure relates to methods, devices, systems, and non-transitory computer-readable storage media for performance monitoring based on instruction blocks. According to some examples, an apparatus includes: execution hardware for executing a plurality of instructions; and block-based sampling hardware. The block-based sampling hardware is used to: identify an instruction block based on a first branch instruction in the plurality of instructions and a second branch instruction in the plurality of instructions; and collect performance information during execution of the instruction block.

[0016] As mentioned in the background section, various techniques can be used to collect data for analyzing the performance of hardware and software on computers and other information processing systems. As described below, the difficulty of using these techniques may hinder the analysis and optimization of multiple layers of hardware and software.

[0017] Overlapping execution of instructions can make it difficult to understand which resource bottlenecks or dependency stalls affect instruction-level parallelism, especially as instructions with high range core execution latencies (such as Intel's AVX512, Intel's AMX, etc.) become more commonly mixed with simple instructions in varying proportions.

[0018] Some instruction-based sampling (IBS) techniques (e.g., ProfileMe) may have an "averaging" or "smearing effect" across their sampled set (e.g., by using tools such as perf, emon, pmc that statistically attribute contributions of different microarchitectural bottlenecks to a cycle per instruction (CPI) metric averaged across all instructions), which may make it difficult to gain a clear understanding of which issues are stalling various classes of instructions (e.g., Intel's AVX, Intel's AMX, AMD's VAES, etc.) at specific points in time (e.g., when there is a sudden spike in or around a specific set of code paths). Synthesizing a path-oriented view may include stitching together paths by creating statistical profiles for them (e.g., by synthesizing the path profiles and mapping out the interesting portions from the IBS profiles), thereby exacerbating the problem of neighboring instructions having their IBS profiles collected at different sampling times.

[0019] Techniques such as Intel's Top-down Microarchitectural Analysis (TMA) provide stall metrics that can be interpreted across all threads of a shared socket because they attribute stalls to different primary causes. This analysis is based directly on total event counts of different types (i.e., not sampling-based), but aggregates the impact of microarchitectural stalls across all instructions in each window of execution time, making it difficult to decompose the results into small but statistically significant increases in the average CPI across different code paths within the application without assuming that the workload is in a steady state within the window.

[0020] Some types of analysis may be centered around traces (instruction traces, system event traces, memory address traces, disk block traces, etc.), since sampling can sometimes be too coarse-grained. Analysis may include cross-correlating traces with each other, and with other non-trace outputs, in order to identify phenomena worth digging into. Currently, such collection, filtering, and correlation steps are either done in software, or require software oversight even when migrated to capable hardware.

[0021] Different types of traces may be collected together if their memory and central processing unit (CPU) overhead is small, and may be collected separately in different executions if the behavior of the workload can be assumed to be sufficiently repeatable. Similarly, non-trace outputs may be collected separately from each other or together, and may be collected separately from or together with trace collections, depending on whether these collections may have cross-contamination effects. If the workload pattern is not stable between different executions, these techniques may involve prioritizing which trace and non-trace outputs to collect together to identify cross-cutting issues.

[0022] Correlations between different traces, and between trace and non-trace output, are difficult to draw unless all such traces and other non-trace metrics are concurrent (so that they come from the same execution sequence); however, since many types of traces may interfere with workload performance (and distort what is being traced), it may be impractical to collect all but a few types of traces concurrently. Collecting multiple (e.g., non-concurrent) trace sets and fusing them together may involve careful alignment of the traces so that they cover more or less the same interesting behavior. As a result, these activities may be expert-intensive and error-prone.

[0023] Understanding system behavior may involve knowledge of the "data" side (e.g., value profiling). For example, determining whether an application may benefit from being ported to use an accelerator (e.g., Intel's Data Streaming Accelerator or DSA) may involve understanding the distribution of the sizes of its streaming memory operations and the frequency of those memory operations. Similarly, determining whether to vectorize a particular computation involves obtaining the distribution of the parameters with which the procedure used to perform the computation is called. For example, if 90% or more of dot products are done on vectors smaller than a threshold amount (e.g., 32 elements), any speedup from AVX use may be offset by the other costs of setting up the data for AVX use.

[0024] Thus, analysis may involve running an instrumented execution (value profiling code inserted by software / compilers, or through Pin-based dynamic instrumentation, which runs the binary through software emulation of a CPU). With this technique or similar interpretation processes, unless the value profiles collected for a small portion of the execution are known to be representative of the rest of the execution, it may be impractical to perform value profiling, as this approach typically slows down execution by several orders of magnitude, and may only be practically employed on a small scale (e.g., one or a few CPUs, and typically with emulated (uninstrumentable) system calls).

[0025] Analyzing network, input / output (I / O), and / or memory performance may involve monitoring separate event streams, and correlating events between them may involve statistical analysis. The dynamics between these subsystems in production workloads (e.g., back pressure due to slower, delayed garbage collection) may be lost in such statistical analysis.

[0026] Use of the embodiments described below may be expected to alleviate difficulties of the types described above, for efficient and adaptive utilization of performance monitoring resources in hardware, and for automating the discovery of emergent behaviors of the system and adapting to them without concern for the overhead and latency of such automation and adaptation.

[0027] Figure 1A The diagram illustrates a telemetry system (smart telemetry device 100) according to an embodiment, such as may be referred to as a smart or actionable telemetry system because it is energy efficient, non-intrusive, multi-point, multi-party, etc. Embodiments based on such telemetry systems may minimize the movement of telemetry data and combine flexible, lightweight, and adaptive near real-time monitoring with low latency through a variety of common programmable actions, as well as customized filtering and triggering actions.

[0028] The telemetry system on which the embodiments may be based may include different types of telemetry, which may originate from different sources that may or may not be tightly coupled. Such telemetry may be referred to as multi-point multi-party telemetry, and may include a multi-point multi-party event stream (MMES110), which includes but is not limited to: event logs, block tracking, performance monitor counters (PMC) counts, event-based sampling (EBS) samples, time-based sampling (TBS) samples, system software events (e.g., system activity reports (SAR), performance scheduling), event streams generated by application software, and other event streams (e.g., from accelerators). The source of the telemetry stream may include CPUs, accelerators, network interfaces, other hardware units, layers of the software stack from supervisory programs to user-level entities (e.g., threads, tasks, modules, utilities, subsystems, etc.). Further, the source of such telemetry streams for a workload or for a chain of microservices may run on multiple hosts in a cluster and may further span autonomously executing agents like smart network interface controllers (NICs), smart storage devices, database appliances, etc.

[0029] The smart telemetry device 100 may include an observer 102 for receiving information from the MMES 110, an aggregator 104 for aggregating information, an inference tool (e.g., a model, a decision tree, etc.) 106 for using raw data and / or aggregated data to generate inferences, and a trigger 108 for generating triggers based on inferences. These triggers can be used by various software subsystems such as Kafka, Elastic Search, Kibana, KVS, InfluxDB, Fluent, etc. to provide analysis and visualization 122, indexing and search 124, and alerts and notifications 126 for different goals, and to coordinate potentially conflicting requirements and service level objectives across multiple parties (e.g., owners of hardware and networking infrastructure, owners of virtual machines and containers, owners of application developers, owners of system reliability engineers, software service owners, performance engineers, etc.).

[0030] Data from both raw telemetry and output from smart telemetry devices can be used, for example, to characterize performance, manage availability and provisioning, isolate throughput, latency or scaling factors, perform parameter sweeps for optimization, shape or regulate traffic, load balance, change software and / or hardware configurations to improve various figures of merit such as response time, request rate, utilization, efficiency, headroom, power consumption, and the like.

[0031] According to an embodiment, a telemetry system such as the smart telemetry device 100 may be included in a computer or information processing system such as Figure 4 ) and / or provide information to a computer or information processing system such as Figure 4 ), combined with block-based performance monitoring, as further described below.

[0032] Figure 1B FIG. 1 illustrates a processor core supporting block-based performance monitoring according to an embodiment. According to an embodiment, block-based performance monitoring may be implemented in a processor, a processor core, an execution core, etc. The processor, the processor core, the execution core, etc. may be any type of processor / core, including a general-purpose microprocessor / core, such as Processor series or from A processor / core from another processor family of Intel® or another company, a special purpose processor or microcontroller, or any other device or component in an information handling system in which embodiments may be implemented.

[0033] For example, Figure 1B A processor or processor core 150 (which may represent any of the following) supporting block-based performance monitoring according to an embodiment is illustrated. Figure 4 The processor 470, 480 or 415 in the system 400, Figure 5 processor 500 or one of cores 502A to 502N in the embodiment of the present invention, and / or Figure 6B For convenience and / or example, some features (e.g., instructions) may be implemented by being associated with a particular processor architecture (e.g., 64 and / or IA32), but the embodiments are not limited to those features, names, architectures, etc.

[0034] As shown, processor core 150 includes a performance monitoring unit (PMU) 160, an instruction unit 170, a configuration storage device (e.g., model or machine specific registers (MSRs)) 180, (one or more) execution units 190, and any other elements not shown.

[0035] PMU 160 may represent and / or include any circuitry, logic gates, structures, and / or other hardware for and / or supporting performance monitoring according to any known techniques and / or according to an embodiment.

[0036] The instruction unit 170 can be used with Figure 6B The front end unit 630 corresponds to and / or is implemented / included in Figure 6B The front end unit 630 in the embodiment of the present invention may include any circuit system, logic gates, structures and / or other hardware (such as an instruction decoder) to obtain, receive, decode, interpret, schedule and / or handle instructions or programming mechanisms to be executed and / or processed by the processor core 150, such as the insert event instruction (INSEVNT) represented as block 172 described below. Figure 1B In , instructions that may be decoded or otherwise handled by instruction unit 170 are represented as blocks with dashed boundaries because the instructions themselves are not hardware, but instruction unit 170 may include hardware or logic capable of decoding or otherwise handling these instructions.

[0037] Any instruction format may be used in embodiments; for example, an instruction may include an opcode and one or more operands, where the opcode may be decoded into one or more microinstructions or micro-operations for execution by an execution unit. The operands or other parameters may be associated with the instruction implicitly, directly, indirectly, or in any other manner.

[0038] Configuration storage 180 may include any one or more MSRs or other registers or storage locations, one or more of which may be within the core and / or one or more of which may be outside the core (e.g., in an uncore, a system agent, etc.) to control processor features, control and report on processor performance, handle system-related functions, etc. In various embodiments, one or more of these registers or storage locations may or may not be accessible to applications and / or user-level software, may be written to or programmed by software, a basic input / output system (BIOS), etc.

[0039] In an embodiment, the instruction set of processor core 150 may include instructions for accessing (e.g., reading and / or writing) MSRs or other storage devices, such as instructions for writing to MSRs (WRMSR), and / or instructions for writing to or programming other registers or storage locations.

[0040] In an embodiment, configuration storage 230 may include one or more instruction event address registers (IEARs) as described below, which may correspond to MSRs, fields or portions of MSRs, or other programmable storage locations.

[0041] Execution unit(s) 190 may be associated with Figure 6B The execution engine 650 or Figure 7 The execution unit circuit system 662 in the embodiment corresponds to and / or is implemented / included in Figure 6B The execution engine 650 or Figure 7 In the execution unit circuit system 662, as described below.

[0042] Embodiments may include hardware support for basic block (e.g., path segments in a graphical representation of a computation) and chained basic block profiling for extending IBS to operate at basic block granularity and combining it with a variant of timed branch (e.g., Intel's Last Branch Recording or LBR) profiling. In embodiments, basic blocks may be viewed as "super instructions" for transforming IBS techniques into basic block based sampling (BBS) techniques or basic block based profiling techniques. Provisions for executable telemetry systems may provide for aggregating such observation streams to efficiently profile basic blocks that are traversed serially by focusing on a path segment by path segment basis rather than current instruction sampling techniques.

[0043] For example, Figure 2A An IBS method 200 is shown, which can be extended as follows Figure 2B The BBS method 250 shown in FIG. Figure 2A, processor hardware (e.g., a performance monitoring unit or PMU) selects (in 210) an instruction from time to time (e.g., at some configured frequency or sampling after a value for an instruction count) and tracks (in 212) it so that the micro-operations generated thereby (including their data access steps) are monitored (in 216) for things such as their translation lookaside buffer (TLB) hits or misses, cache hits or misses, data access latencies, the various data addresses it generates during its execution (214) (in 218), etc. When it reaches retirement, this record of all the things being tracked is transferred (in 220) to a data structure in response to a signal (in 224) generated from the PMU via the raising and handling (in 222) of an interrupt. Implementations may employ buffering so that the interrupt frequency may be reduced. Thus, for a representative sample of executed and retired instructions, a large amount of detail (akin to a "day in the life of an instruction") is recorded, and then the various correlations or ratios observed across the sampled, retired instructions are summarized to also apply to all instructions including those that were not selected and traced. Intuitively, the key benefit of this approach is that different events that are correlated have an underlying common factor because they are statistically related to each other by virtue of being closely tied to a common population of traced instructions.

[0044] Similar approaches include ProfileMe, which uses paired sampling to investigate neighboring instructions as a whole and considers overlap between instructions, and Intel's processor event-based sampling (PEBS), which collects and analyzes memory load events (e.g., cache and TLB misses) in the context of instructions traced to retirement.

[0045] Embodiments extend the above concepts beyond single instruction to multi-instruction based sampling using a new sampling unit (basic block). In highly vectorized code where masked operations may be used, basic blocks may become quite significant in terms of cycles or micro-ops at the CPU, but the counting itself may be very economical. In embodiments, BBS involves sampling the retired branch instruction that signals the start of a basic block, and continuing to track until the next branch instruction that is retired. The BBS method 250 according to embodiments is Figure 2B is shown in the figure.

[0046] In 252 of method 250, a branch instruction is retired. In 254, tracing of the instruction following the branch instruction begins. In 256, for each type of performance event encountered during tracing, an event count for that type of performance event is incremented, and wait times for events of the same type are aggregated. In 260, a PMU interrupt is generated in response to the next branch instruction. In 262, the PMU handler (e.g., in response to the trigger generated in 260) records the collected sum of event counts and wait times (by event type) into a software buffer. In 264, the event counts and wait times are cleared in preparation for retirement of the next branch instruction.

[0047] In an embodiment, method 250 can be extended to loops covering consecutive iterations of the same basic block (high frequency basic block loops), and such loops are treated as giant BBS profiling. For example, multiple back-to-back branch retirements (e.g., in 252 of method 250) with the same target branch address can be linked. It can also be extended by extending LBR (and / or timed LBR) based profiling to build path profiles and aggregate path metrics (e.g., when one side of a branch is occupied with overwhelming frequency, thereby the path becomes a pseudo basic block).

[0048] Thus, embodiments can provide chained tracing by treating basic blocks as composite units of sequential execution of micro-operations, which are larger in granularity than micro-operations associated with only instructions. Basic blocks can be included in most of the data dependencies inside them, and the branches between basic blocks depict control flow dependencies and legacy data dependencies (not fully captured in one basic block). Basic loop profiling and pseudo basic block profiling make IBS very close to the richness of tracing, but without high overhead. Embodiments can also provide an increased surface area for sampling and profiling, because in optimization techniques, it becomes common to adopt inlining and silent branch elimination by masks, conditional moves, etc. Comprehensive optimization similar to inlining can extend the scope of the content captured in the basic block, and the use of asserted operations (e.g., used together with masks in AVX, and used as conditional moves to flatten many control dependencies in performance-critical code paths).

[0049] In embodiments, basic blocks, basic loops, and pseudo basic blocks may be viewed as composite instructions whose execution stalls are better correlated with other basic blocks as a whole rather than with constituent instructions, particularly since basic blocks may contain within them a wide range of instruction complexities, from instructions that may have very little front-end effect and whose stalls are at one extreme correlated with almost all back-end resource instructions, to instructions that may be tens of cycles and may hide many cache miss latencies due to their data and operation parallelism (e.g., AMX instructions).

[0050] Embodiments may also include a new Insert Event instruction (INSEVNT) that may be used, for example, to insert an event describing a data structure into a logical location in a trace record. The data structure may have one or more fields that permit one or more trace streams to be linked as related. These fields may also permit trace streams to be related to the latest value output from a sequence (e.g., Observe-Aggregate-Filter) programmed by software into the executable telemetry system. In combination, these features may be used in embodiments to create a "super trace" stream, where individual traces are augmented with timely non-trace outputs and with links to homologous points in other trace streams.

[0051] Such embodiments provide for inserting software counters and events into hardware collected event traces, and cross-linking traces to each other and to general non-trace outputs from executable telemetry. Non-trace outputs may include interval metrics such as instruction retirements, LLC cache misses, clock cycles, cache hits / misses, etc., and / or their CPI-like ratios, LLC misses per instruction (LLCMPI), etc., and / or their linear / exponential moving window averages, etc. Traces and events may each be represented by a handle with a runtime dynamic mapping between a trace handle and a stream offset into which an event handle in the trace handle is to be inserted.

[0052] In an embodiment, the INSEVNT instruction format may include an INSEVNT opcode field, a first operand field for handles (EHANDLE), and a second operand field for tracking (TRC).

[0053] In an embodiment, a mapping between EHANDLEs and data records, or a mapping between TRCs and insertion points in a trace referenced by the TRC (where events are to be inserted), can be provided by software utility routines (e.g., in a performance library) so that different forms of tracing and event insertion mechanisms can be abstracted from their low-level implementation details.

[0054] In an embodiment, EHANDLE may be implicitly mapped to a data record. The record may be flat and / or cache line aligned and in units of cache line size (e.g., 64 bytes), but other variations are possible. As an example, a 64-byte record may include the fields shown in Table 1. Table 1

[0055] In an embodiment, the data structure associated with the inserted event can be constructed by the caller of the INSEVNT instruction. If the execution of the INSEVNT instruction fails (for example, because TRC is an invalid value), the execution of the INSEVNT instruction can set the ZERO flag. TRC can be a valid or invalid memory address. If valid, it is the memory-mapped channel at which the active telemetry mechanism receives the inserted event. If invalid, it means that the active telemetry mechanism is not currently active or is in the process of being shut down.

[0056] It may be expected that the use of embodiments may provide the ability to insert events and cross-link these events beyond the PTWRITE capability in Intel Processor Trace (IPT). Although PTWRITE injects specific metrics (similar to LLCMPI) into IPT records (the IPT records have a very specific structure designed for compact representation of instruction addresses / offsets), embodiments including INSEVNT can provide general event tracking, which may have a very flexible structure depending on observers, aggregators, recorders, etc. This generalization can give the ability to logically introduce tracking elements in a stream (for example, there may be an umbrella data structure that indexes event tracking, and associates these indexes with other data items created by software to merge software counters from system software (for example, operating system), libraries and / or applications, and software events such as log entries, and event tracking). Therefore, embodiments provide software with the flexibility to associate information in parallel buffers and to closely associate each index with a handle. Further, by cross-linking between events inserted into different traces or into the same trace at different insertion points, embodiments provide for isolating segments whose traces are contemporaneous with each other (e.g., in time), thereby simplifying online analysis that may need to reference multiple traces.

[0057] Other telemetry capabilities may be provided in these or other embodiments, which may also or alternatively include one or more new configuration registers (or other storage locations), which may be per-CPU, per-core, etc. Each of the configuration registers may be used to specify a position index between a call-branch target and an argument of the call-branch target (e.g., identifying one of its parameters). When a retired call instruction causes the instruction pointer to reach the specified call-branch target, a mechanism may be triggered, and the mechanism may read the corresponding position parameter value and supply it to an executable telemetry observer component, which updates a profile of values ​​that have been collected up to the current time. Thus, the hardware may be programmed to pluck out parameter values ​​on the fly (e.g., at the time of a procedure call) and have the parameter value processed by the executable telemetry mechanism without interrupting or slowing down the executing application.

[0058] Such embodiments may provide aggregation (e.g., software-guided) of parameter values ​​(e.g., in a software call stack) to enable low-overhead, flexible value profiling. It may be desirable to use embodiments in performance investigation and optimization situations where it is often insightful to be able to profile software behavior by intercepting parameter values ​​at key procedure calls in different software layers (including, but not limited to, syscall parameters). In highly layered code, heavily templated code, and polymorphic languages ​​(where instrumenting code paths to extract parameters and constructing histograms, percentiles, and other statistical properties of call parameters may not be trivial), use of embodiments may be preferred over the alternative approach of running instructions through instruction emulation using tools such as Valgrind, Pin, SDE, etc., which may distort the speed of execution (e.g., by orders of magnitude) and distort the scale at which profiling can be done.

[0059] In an embodiment, the mechanisms described further below may be given a code address at which sampling is performed in a statistical manner such that one call frame out of a certain number (e.g., 100, 1000, etc.) of call frames is collected and parameter values ​​are extracted for profiling.

[0060] Figure 3AA stack frame 300 (or call frame layout or call stack) is shown when a calling procedure A has called another procedure B. In some cases, the frame pointer may be optimized so that registers (e.g., %rbp) can be used for general purposes. In any case, for the top frame in the stack, extracting the parameter positions from the standardized layout may be relatively straightforward (not considering the case where the call (e.g., function call) is inlined, as that may involve additional support from software and compilers). The layout for the call stack frame may vary between different compiler options, language application binary interface (ABI), etc., but the layout is recorded in each case and is known at runtime.

[0061] The value profiling method according to an embodiment can be implemented in software (e.g., for low-frequency sampling) and in programmed hardware under executable telemetry (e.g., for high-frequency sampling and non-destructively aggregated into histograms for callee processes and their parameters of interest). For ease of description, a hardware-assisted lightweight method is described first, followed by a simplified but lower-frequency sampling variant of the method without hardware assistance.

[0062] According to the hardware-assisted method, the setup includes providing a small number of instruction event address registers (IEAR) to the software (e.g., via an executable telemetry system), which the software tool uses in order to specify which procedures and the (one or more) parameters of those procedures are to be extracted for value distribution. For example, the location of the kth parameter is known from the stack pointer value upon entry into the function, such as Figure 3A ) (e.g., for the kth value below the offset of the return address). Software can then choose when to activate or deactivate the programmed setting, which allows software tools to control the time range or conditions under which the call parameter profile is to be extracted.

[0063] When activated, hardware assistance (which can be an extension of the PMU logic) such as Figure 3B. Method 310 includes observing call instructions and sampling call instructions, as represented by 312. In 320, the call instruction is retired. In 322, it is determined that the target of the call-branch matches one of the programmed and activated IEARs. In response, in 324, (e.g., by the processor microarchitecture) the expected parameter value is extracted by making the correct distance offset from the current register stack pointer (as described above, the correct distance can be pre-calculated and entered into the IEAR in advance). Also in response, in 324, the return address is extracted. In 326, the parameter value and the return address are forwarded to the observer. The return address may be useful in the following case: when there is a need for disambiguation between different parameter profiles according to multiple caller-callee relationships, so that aggregation is only performed along some but not all paths into the caller.

[0064] A software-only alternative can be implemented by writing a debugger script. Instead of a new IEAR and hardware for executing the above method, the software can program one of the available debug registers to observe the expected callee entry point. It will then read the stack location at the expected offset when the callee entry point is hit, and write the value of the parameter out to the buffer. It will also extract the return address and place it in the buffer as well. Then, before repeating the same process, it will suspend the debugger for a certain length of time. A separate thread will run from time to time and collect the contents of the buffer, and perform different desired aggregations directly in software, because the frequency at which the buffer needs to be collected can be coarse-grained in the software alternative.

[0065] According to a further extension, a software method may accept four parameters: the callee entry point address, its parameters to be profiled, the number of indirections to be performed on the parameters to reach the value to be profiled, and the type of aggregation to be performed on the value. This approach provides for the profiling of values ​​that may not appear directly in the arguments of the function, but are linked with a pointer from one of those arguments. Optionally, the software-based indirect value profiling mechanism also remains fault-tolerant, so that it catches segment violation signals (e.g., SIGSEGV) delivered by the OS and terminates the profiling gracefully if it reaches an unmapped value due to such indirection.

[0066] Additionally or alternatively, software-only methods may be applied via script processing (e.g., utilizing extended or enhanced Berkeley Packet Filtering or eBPF), where the callees are tracepoints or probe points (e.g., eBPF-based) exposed for monitoring.

[0067] Example Apparatus, Methods, etc.

[0068] According to some examples, an apparatus (e.g., a processing device or system) includes: execution hardware for executing a plurality of instructions; and block-based sampling hardware. The block-based sampling hardware is used to: identify an instruction block based on a first branch instruction in the plurality of instructions and a second branch instruction in the plurality of instructions; and collect performance information during execution of the instruction block.

[0069] Any such example may include any of the following aspects or any combination thereof. Block-based sampling hardware is used to identify the beginning of an instruction block in response to the retirement of a first branch instruction. Block-based sampling hardware is used to identify the end of an instruction block in response to the retirement of a second branch instruction. Collecting performance information includes counting the occurrence of a type of event. Collecting performance information includes aggregating wait times for a type of event. Performance information is used to be collected into a trace record. The device also includes an instruction decoder for decoding an insert event instruction, wherein, in response to the insert event instruction, the block-based hardware is used to insert a data structure into the trace record. The insert event instruction is used to indicate a handle to the data record. The insert event instruction is used to indicate an insertion point in the trace record. The device also includes a storage location for storing an instruction event address. The instruction event address is based on a call branch target. The instruction event address is also based on an index associated with a parameter of the call branch target. The block-based sampling hardware is also used to trigger an update value profile in response to a match related to the retirement of the call branch instruction. The block-based sampling hardware is also used to perform pointer dereference related to call parameter profiling.

[0070] According to some examples, a method includes identifying, by block-based sampling hardware, an instruction block based on a first branch instruction in a plurality of instructions and a second branch instruction in the plurality of instructions; and collecting, by the block-based sampling hardware, performance information during execution of the instruction block.

[0071] Any such examples may include any of the following aspects or any combination thereof. Identifying an instruction block includes: identifying the beginning of the instruction block in response to the retirement of a first branch instruction. Performance information is collected in a trace record, and the method further includes: inserting a data structure into the trace record in response to an insert event instruction. The method further includes: updating a value profile in response to an instruction event address match related to the retirement of a call branch instruction.

[0072] According to some examples, a system includes: a telemetry system; execution hardware for executing multiple instructions; and block-based sampling hardware for identifying an instruction block based on a first branch instruction in the multiple instructions and a second branch instruction in the multiple instructions, and for collecting telemetry information from the telemetry system during execution of the instruction block.

[0073] Any such example may include any of the following aspects or any combination thereof. Block-based sampling hardware is used to identify the beginning of an instruction block in response to the retirement of a first branch instruction. Block-based sampling hardware is used to identify the end of an instruction block in response to the retirement of a second branch instruction. Collecting performance information includes counting the occurrence of a type of event. Collecting performance information includes aggregating wait times for a type of event. Performance information is used to be collected into a trace record. The system also includes an instruction decoder for decoding an insert event instruction, wherein, in response to the insert event instruction, the block-based hardware is used to insert a data structure into the trace record. The insert event instruction is used to indicate a handle to the data record. The insert event instruction is used to indicate an insertion point in the trace record. The system also includes a storage location for storing an instruction event address. The instruction event address is based on a call branch target. The instruction event address is also based on an index associated with a parameter of the call branch target. The block-based sampling hardware is also used to trigger an update value profile in response to a match related to the retirement of the call branch instruction.

[0074] According to some examples, a device may include means for performing any function disclosed herein; a device may include a data storage device storing code, which, when executed by a hardware processor or controller, causes the hardware processor or controller to perform any method or any part of a method disclosed herein; the device, method, system, etc. may be as described in the detailed description; a non-transitory machine-readable medium may store instructions, which, when executed by a machine, causes the machine to perform any method or any part of a method disclosed herein. Embodiments may include any details, features, etc. described in this specification or a combination of details, features, etc.

[0075] Example Computer Architecture

[0076] The following is a description of an example computer architecture. Other system designs and configurations known in the art for laptops, desktop computers, and handheld personal computers (personal computers, PCs), personal digital assistants, engineering workstations, servers, decomposed servers, network devices, network hubs, switches, routers, embedded processors, digital signal processors (digital signal processors, DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices are also appropriate. In a word, various systems or electronic devices that can include processors disclosed herein and / or other execution logics are generally appropriate.

[0077] Figure 4An example computing system is illustrated. Multiprocessor system 400 is an interface system and includes multiple processors or cores, including a first processor 470 and a second processor 480 coupled via an interface 450 such as a point-to-point interconnect (PP), a fabric, and / or a bus. In some examples, the first processor 470 and the second processor 480 are isomorphic. In some examples, the first processor 470 and the second processor 480 are heterogeneous. Although example system 400 is shown as having two processors, the system can have three or more processors, or can be a single processor system. In some examples, the computing system is a system on chip (SoC).

[0078] Processors 470 and 480 are shown as including integrated memory controller (IMC) circuitry 472 and 482, respectively. Processor 470 also includes interface circuits 476 and 478; similarly, second processor 480 includes interface circuits 486 and 488. Processors 470, 480 may exchange information via interface 450 using interface circuitry 478, 488. IMCs 472 and 482 couple processors 470, 480 to respective memories, namely memory 432 and memory 434, which may be part of the main memory locally attached to the respective processors.

[0079] Processors 470, 480 may each utilize interface circuitry 476, 494, 486, 498 to exchange information with a network interface (NW I / F) 490 via respective interfaces 452, 454. Network interface 490 (e.g., one or more of an interconnect, bus, and / or fabric, and in some examples, a chipset) may optionally exchange information with a coprocessor 438 via interface circuitry 492. In some examples, coprocessor 438 is a special-purpose processor such as, for example, a high-throughput processor, a network or communication processor, a compression engine, a graphics processor, a general purpose graphics processing unit (GPGPU), a neural-network processing unit (NPU), an embedded processor, and the like.

[0080] A shared cache (not shown) may be included in either processor 470, 480, or external to both processors but connected to the processors via an interface such as a PP interconnect, such that if a processor is placed in a low power mode, local cache information of either or both processors may also be stored in the shared cache.

[0081] The network interface 490 can be coupled to the first interface 416 via the interface circuit 496. In some examples, the first interface 416 can be an interface such as a Peripheral Component Interconnect (PCI) interconnect, a PCI Express interconnect, or another I / O interconnect. In some examples, the first interface 416 is coupled to a power control unit (PCU) 417, which can include circuit systems, software, and / or firmware to perform power management operations with respect to the processors 470, 480, and / or the coprocessor 438. The PCU 417 provides control information to a voltage regulator (not shown) so that the voltage regulator generates an appropriate regulated voltage. The PCU 417 also provides control information to control the generated operating voltage. In various examples, the PCU 417 can include various power management logic units (circuitry systems) to perform hardware-based power management. Such power management may be entirely processor controlled (e.g., controlled by various processor hardware and may be triggered by workload and / or power constraints, thermal constraints, or other processor constraints), and / or power management may be performed in response to an external source (such as a platform or power management source or system software).

[0082] PCU 417 is illustrated as existing as logic separate from processor 470 and / or processor 480. In other cases, PCU 417 may execute on a given one or more cores in the core (not shown) of processor 470 or 480. In some cases, PCU 417 may be implemented as a microcontroller (dedicated or general purpose) or other control logic that is configured to execute its own dedicated power management code (sometimes referred to as P-code). In yet other examples, the power management operations to be performed by PCU 417 may be implemented outside the processor, such as by a separate power management integrated circuit (PMIC) or another component external to the processor. In yet other examples, the power management operations to be performed by PCU 417 may be implemented within the BIOS or other system software.

[0083] Various I / O devices 414 and a bus bridge 418 can be coupled to the first interface 416, and the bus bridge 418 couples the first interface 416 to the second interface 420. In some examples, one or more additional processors 415 are coupled to the first interface 416, such as a coprocessor, a high-throughput integrated many-core (MIC) processor, a GPGPU, an accelerator (such as a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor. In some examples, the second interface 420 can be a low pin count (LPC) interface. Various devices can be coupled to the second interface 420, including, for example, a keyboard and / or mouse 422, a communication device 427, and a storage circuit system 428. The storage circuit system 428 can be one or more non-transitory machine-readable storage media such as a disk drive or other mass storage device as described below, which may include instructions / codes and data 430. Further, audio I / O 424 can be coupled to second interface 420. Note that other architectures are possible in addition to the point-to-point architecture described above. For example, systems such as multiprocessor system 400 can implement a multi-drop interconnect or other such architectures instead of a point-to-point architecture.

[0084] Exemplary core architectures, processors, and computer architectures.

[0085] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of these cores may include: 1) general-purpose in-order cores, for general-purpose computing purposes; 2) high-performance general-purpose out-of-order cores, for general-purpose computing purposes; 3) special-purpose cores, mainly for graphics and / or scientific (throughput) computing purposes. Implementations of different processors may include: 1) a CPU, including one or more general-purpose in-order cores for general-purpose computing purposes and / or one or more general-purpose out-of-order cores for general-purpose computing purposes; and 2) a coprocessor, including one or more special-purpose cores mainly for graphics and / or scientific (throughput) computing. These different processors result in different computer system architectures, which may include: 1) coprocessors on separate chips from the CPU; 2) coprocessors on separate dies from the CPU in the same package; 3) coprocessors on the same die as the CPU (in which case such coprocessors are sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or as dedicated cores); and 4) systems on a chip (SoCs), which may be included on the same die as the described CPU (sometimes referred to as application core(s) or application processor(s), the coprocessors described above, and additional functionality. An example core architecture is described next, followed by a description of an example processor and computer architecture.

[0086] Figure 5 A block diagram of an example processor and / or SoC 500 is illustrated, which may have one or more cores, and an integrated memory controller. The processor 500 illustrated in solid line blocks has a single core 502(A), a system agent unit circuitry 510, and a set of one or more interface controller unit circuitry 516, while the optionally added dashed line blocks illustrate an alternative processor 500 as having multiple cores 502(A)-(N), a set of one or more integrated memory control unit circuitry 514 in the system agent unit circuitry 510, dedicated logic 508, and a set of one or more interface controller unit circuitry 516. Note that the processor 500 may be Figure 4 One of the processors 470 or 480 or the coprocessors 438 or 415.

[0087] Thus, different implementations of processor 500 may include: 1) a CPU, where dedicated logic 508 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 502(A)-(N) are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, or a combination of the two); 2) a coprocessor, where cores 502(A)-(N) are a large number of dedicated cores primarily for graphics and / or scientific (throughput) purposes; and 3) a coprocessor, where cores 502(A)-(N) are a large number of general purpose in-order cores. Thus, processor 500 may be a general purpose processor, a coprocessor, or a special purpose processor, such as a network or communication processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit), a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. Processor 500 may be part of and / or may be implemented on one or more substrates using any of a variety of process technologies, such as, for example, complementary metal oxide semiconductor (CMOS), bipolar CMOS (BiCMOS), P-type metal oxide semiconductor (PMOS), or N-type metal oxide semiconductor (NMOS).

[0088] The memory hierarchy includes one or more levels of cache unit circuitry 504(A)-(N) within the cores 502(A)-(N), a set of one or more shared cache unit circuitry 506, and external memory (not shown) coupled to the set of (one or more) integrated memory controller unit circuitry 514. The set of one or more shared cache unit circuitry 506 may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (4), or other levels of cache, such as last level cache (LLC), and / or combinations thereof. While in some examples, an interface network circuitry 512 (e.g., a ring interconnect) provides an interface to the dedicated logic 508 (e.g., integrated graphics logic), the set of (one or more) shared cache unit circuitry 506, and the system agent unit circuitry 510, alternative examples use any number of well-known techniques to provide interfaces to these units. In some examples, coherency is maintained between one or more circuitry in the (one or more) shared cache unit circuitry 506 and the cores 502(A)-(N). In some examples, the interface controller unit circuit system 516 couples the core 502 to one or more other devices 518, such as one or more I / O devices, storage devices, one or more communication devices (e.g., wireless networking, wired networking, etc.), and the like.

[0089] In some embodiments, one or more of the cores 502(A)-(N) have multithreading capabilities. The system agent unit circuit system 510 includes those components that coordinate and operate the cores 502(A)-(N). The system agent unit circuit system 510 may include, for example, a power control unit (PCU) circuit system and / or a display unit circuit system (not shown). The PCU may be (or may include) the logic and components required to regulate the power state of the cores 502(A)-(N) and / or the dedicated logic 508 (e.g., integrated graphics logic). The display unit circuit system is used to drive one or more externally connected displays.

[0090] The cores 502(A)-(N) may be homogeneous with respect to an instruction set architecture (ISA). Alternatively, the cores 502(A)-(N) may be heterogeneous with respect to an ISA; that is, a subset of the cores 502(A)-(N) may be capable of executing an ISA, while other cores may be capable of executing only a subset of that ISA or a subset of another ISA.

[0091] Example core architectures - in-order and out-of-order core block diagrams.

[0092] Fig. 6AThe block diagram of illustrates both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to an example. Figure 6B The block diagram illustrates both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor according to an example. Figure 6A-6B The solid line boxes in illustrate the in-order pipeline and in-order core, while the optionally added dashed line boxes illustrate the register renaming, out-of-order issue / execution pipeline and core. Considering that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0093] exist Fig. 6A , the processor pipeline 600 includes a fetch stage 602, an optional length decode stage 604, a decode stage 606, an optional allocation (Alloc) stage 608, an optional rename stage 610, a dispatch (also called dispatch or issue) stage 612, an optional register read / memory read stage 614, an execute stage 616, a write back / memory write stage 618, an optional exception handling stage 622, and an optional commit stage 624. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 602, one or more instructions are fetched from the instruction memory, and during the decode stage 606, the fetched one or more instructions may be decoded, an address using a forwarding register port (e.g., a load store unit (LSU) address) may be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) may be performed. In one example, the decode stage 606 and the register read / memory read stage 614 may be combined into one pipeline stage. In one example, during the execution stage 616, decoded instructions may be executed, LSU address / data pipelining to an Advanced Microcontroller Bus (AMB) interface may be performed, multiplication and addition operations may be performed, arithmetic operations with branch results may be performed, and the like.

[0094] As an example, Figure 6BAn example register renaming, out-of-order issue / execution architecture core may implement pipeline 600 by: 1) instruction fetch circuitry 638 performs fetch and length decode stages 602 and 604; 2) decode unit circuitry 640 performs decode stage 606; 3) rename / allocator unit circuitry 652 performs allocate stage 608 and rename stage 610; 4) (one or more) scheduler unit circuitry 656 performs schedule stage 612; 5) (one or more) physical register file unit circuitry 658 and memory unit circuitry 670 perform register read / memory read stage 614; execution cluster 660 performs execute stage 616; 6) memory unit circuitry 670 and (one or more) physical register file unit circuitry 658 perform write back / memory write stage 618; 7) various circuitry may be involved in exception handling stage 622; and 8) retirement unit circuitry 654 and (one or more) physical register file unit circuitry 658 perform commit stage 624.

[0095] Figure 6B Processor core 690 is shown to include front end unit circuitry 630 coupled to execution engine unit circuitry 650, and both are coupled to memory unit circuitry 670. Core 690 may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, core 690 may be a special purpose core, such as a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, and the like.

[0096] The front end unit circuit system 630 may include a branch prediction circuit system 632, which is coupled to an instruction cache circuit system 634, which is coupled to an instruction translation lookaside buffer (TLB) 636, which is coupled to an instruction fetch circuit system 638, which is coupled to a decoding circuit system 640. In one example, the instruction cache circuit system 634 is included in the memory unit circuit system 670 instead of the front end circuit system 630. The decoding circuit system 640 (or decoder) can decode the instruction and generate one or more micro-operations, microcode entry points, microinstructions, other instructions or other control signals as outputs, which are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decoding circuit system 640 may further include an address generation unit (AGU, not shown) circuit system. In one example, the AGU uses the forwarded register port to generate the LSU address and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decode circuit system 640 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read only memory (ROM), and the like. In one example, the core 690 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode circuit system 640 or otherwise within the front-end circuit system 630). In one example, the decode circuit system 640 includes a micro-op or operation cache (not shown) to save / cache decoded operations, micro-tags, or micro-operations generated during decoding or other stages of the processor pipeline 600. The decode circuit system 640 may be coupled to the rename / allocator unit circuit system 652 in the execution engine circuit system 650.

[0097] The execution engine circuitry 650 includes a rename / allocator unit circuitry 652 coupled to a retirement unit circuitry 654 and a set of one or more scheduler circuitry 656. The scheduler circuitry(s) 656 represent any number of different schedulers, including reservation stations, central instruction windows, and the like. In some examples, the scheduler circuitry(s) 656 may include an arithmetic logic unit (ALU) scheduler / scheduling circuitry, an ALU queue, an address generation unit (AGU) scheduler / scheduling circuitry, an AGU queue, and the like. The scheduler circuitry(s) 656 are coupled to physical register file(s) circuitry 658. Each of the physical register file(s) circuitry 658 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, status (e.g., instruction pointers, i.e., the address of the next instruction to be executed), and the like. In one example, the physical register file(s) circuitry 658 includes a vector register unit circuitry, a write mask register unit circuitry, and a scalar register unit circuitry. These register units may provide architectural vector registers, vector mask registers, general purpose registers, and the like. The physical register file(s) circuitry 658 is coupled to a retirement unit circuitry 654 (also referred to as a retirement queue or retirement queue) to demonstrate various ways in which register renaming and out-of-order execution may be implemented (e.g., utilizing a reorder buffer(s) (ROB) and a retirement register file(s); utilizing a future stack(s), a history buffer(s), and a retirement register file(s); utilizing a register map and a pool of registers; and the like). The retirement unit circuitry 654 and the physical register file(s) circuitry 658 are coupled to an execution cluster(s) 660. The execution cluster(s) 660 includes a set of one or more execution unit circuitry 662 and a set of one or more memory access circuitry 664. The execution unit(s) circuit system 662 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point).While some examples may include several execution units or execution unit circuitry dedicated to a particular function or set of functions, other embodiments may include only one execution unit circuitry or multiple execution units / execution unit circuitry that all perform all functions. Scheduler circuitry (s) 656, physical register file circuitry (s) 658, and execution cluster (s) 660 are shown as potentially multiple because some examples create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipelines, and / or memory access pipelines, each with its own scheduler circuitry, physical register file circuitry (s) and / or execution clusters - and in the case of separate memory access pipelines, only the execution cluster of that pipeline has memory access unit circuitry (s) 664 in some examples implemented). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, while the rest are in-order.

[0098] In some examples, the execution engine unit circuitry 650 may perform load store unit (LSU) address / data pipelining to an advanced microcontroller bus (AMB) interface (not shown), as well as address stage and writeback, data stage loads, stores, and branches.

[0099] A set of memory access circuitry 664 is coupled to the memory cell circuitry 670, which includes a data TLB circuitry 672, which is coupled to a data cache circuitry 674, which is coupled to a level 2 (L2) cache circuitry 676. In one example, the memory access circuitry 664 may include a load unit circuitry, a store address unit circuitry, and a store data unit circuitry, each of which is coupled to the data TLB circuitry 672 in the memory cell circuitry 670. The instruction cache circuitry 634 is further coupled to the level 2 (L2) cache unit circuitry 676 in the memory cell circuitry 670. In one example, the instruction cache 634 and the data cache 674 are combined into a single instruction and data cache in the L2 cache circuitry 676, a level 3 (L3) cache circuit (not shown), and / or a main memory (not shown). The L2 cache circuitry 676 is coupled to one or more other levels of cache and ultimately to the main memory.

[0100] Core 690 may support one or more instruction sets (e.g., x86 instruction set architecture (optionally with some extensions that have been added with newer versions); MIPS instruction set architecture; ARM instruction set architecture (optionally with optional additional extensions, such as NEON)) that include the instruction(s) described herein. In one example, core 690 includes logic to support packed data instruction set architecture extensions (e.g., AVX1, AVX2), allowing operations used by many multimedia applications to be performed using packed data.

[0101] Example execution unit(s) circuitry.

[0102] Figure 7 An example of execution unit circuitry, such as Figure 6B (One or more) execution unit circuit systems 662. As illustrated, (one or more) execution unit circuit systems 662 may include one or more ALU circuits 701, optional vector / single instruction multiple data (single instruction multiple data, SIMD) circuits 703, load / store circuits 705, and / or branch / jump circuits 707, and / or floating-point unit (floating-point unit, FPU) circuits 709. ALU circuits 701 perform integer arithmetic and / or Boolean operations. Vector / SIMD circuits 703 perform vector / SIMD operations on packed data (e.g., SIMD / vector registers). Load / store circuits 705 execute load and store instructions to load data from memory into registers, or store data from registers to memory. Load / store circuits 705 may also generate addresses. Branch / jump circuits 707 cause branches or jumps to a certain memory address depending on the instruction. FPU circuits 709 perform floating-point arithmetic. For example, the width of execution unit circuitry 662 varies depending on the example and may range from 16 bits to 1024 bits. In some examples, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit).

[0103] Program code can be applied to input information to perform the functions described herein and generate output information. Output information can be applied to one or more output devices in a known manner. For the present application, processing system includes any system with a processor, such as a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microprocessor, or any combination thereof.

[0104] Program code can be implemented in a process-oriented or object-oriented high-level programming language to communicate with the processing system. If desired, program code can also be implemented in assembly or machine language. In fact, the mechanism described herein is not limited to any specific programming language in scope. In any case, the language can be a compiled language or an interpreted language.

[0105] Examples of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementation approaches. Examples may be implemented as computer programs or program codes, executed on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0106] One or more aspects of at least one example may be implemented by representative instructions stored on a machine-readable medium, which represent various logics within a processor, and which, when read by a machine, cause the machine to make logic for performing the techniques described herein. These representations (referred to as "intellectual property (IP) cores") may be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into a manufacturing machine that makes the logic or processor.

[0107] Such machine-readable storage media may include, but are not limited to, non-transitory tangible arrangements of articles manufactured or formed by a machine or device, including storage media such as: a hard disk, any other type of disk (including floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks), semiconductor devices (e.g., read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase change memory (PCM)), magnetic or optical cards, or any other type of medium suitable for storing electronic instructions.

[0108] Therefore, examples also include non-transitory tangible machine-readable media containing instructions or containing design data, such as hardware description languages ​​(HDL), that define the features of structures, circuits, devices, processors and / or systems described herein. Such examples may also be referred to as program products.

[0109] Emulation (including binary translation, code deformation, etc.).

[0110] In some cases, the instruction converter can be used to convert instructions from a source instruction set architecture to a target instruction set architecture. For example, the instruction converter can translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), deform, simulate or otherwise convert instructions to one or more other instructions to be processed by the core. The instruction converter can be implemented with software, hardware, firmware or a combination thereof. The instruction converter can be on the processor, outside the processor, or partly on the processor and partly outside the processor.

[0111] Figure 81 is a block diagram illustrating the use of a software instruction converter to convert binary instructions in a source ISA into binary instructions in a target ISA according to an example. In the illustrated example, the instruction converter is a software instruction converter, but alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Figure 8 A program in a high-level language 802 is shown to be compiled using a first ISA compiler 804 to generate first ISA binary code 806 that can be natively executed by a processor having at least one first ISA core 816. The processor having at least one first ISA core 816 represents any processor that is capable of executing or otherwise processing (1) a substantial portion of the first ISA or (2) a program that is natively executed by a processor having at least one first ISA core. The first ISA compiler 804 represents a compiler operable to generate first ISA binary code 806 (e.g., object code) that can be executed on a processor 816 having at least one first ISA core with or without additional linking processing. Similarly, Figure 8 It is shown that the program of the high-level language 802 can be compiled using an alternative ISA compiler 808 to generate an alternative ISA binary code 810, which can be executed natively by a processor 814 without a first ISA core. The instruction converter 812 is used to convert the first ISA binary code 806 into a code that can be executed natively by a processor 814 without a first ISA core. This converted code may not be the same as the alternative ISA binary code 810; however, the converted code will implement the overall operation and be composed of instructions from the alternative ISA. Thus, the instruction converter 812 represents software, firmware, hardware, or a combination thereof, which allows a processor or other electronic device without a first ISA processor or core to execute the first ISA binary code 806 through simulation, emulation, or any other process.

[0112] References to "one example," "an example," "one embodiment," "an embodiment," etc. indicate that the described example or embodiment may include a particular feature, structure, or characteristic, but each example or embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same example or embodiment. Further, when a particular feature, structure, or characteristic is described in conjunction with an example or embodiment, it is considered to be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other examples or embodiments, whether or not explicitly described.

[0113] In addition, in the examples described above, unless otherwise specifically noted, delimited language such as phrases "at least one of A, B, or C" or "A, B, and / or C" is intended to be understood to mean A, B, or C, or any combination thereof (i.e., A and B, A and C, B and C, and A, B, and C). As used in this specification and claims, and unless otherwise specified, the use of ordinal adjectives "first," "second," "third," etc., used to describe elements merely indicates that a specific instance of an element or different instances of similar elements are being referenced, and is not intended to imply that the elements so described must be in a particular order in time, space, hierarchically, or in any other manner. In addition, as used in the description of the embodiments, the " / " character between items may mean that what is described may include the first item and / or the second item (and / or any other additional items), or may be implemented using, utilizing, and / or according to the first item and / or the second item (and / or any other additional items).

[0114] In addition, the terms "bit", "flag", "field", "entry", "indicator", etc. may be used to describe a storage location in a register, table, database, or other data structure of any type or content, whether implemented in hardware or software, and these terms are not intended to limit the embodiments to any particular type of storage location or the number of bits or other elements within any particular storage location. For example, the term "bit" may be used to refer to a bit position within a register and / or data stored or to be stored in the bit position. The term "clear" may be used to indicate storing a logic value of 0 in a storage location, or otherwise causing a logic value of 0 to be stored in a storage location; and the term "set" may be used to indicate storing a logic value of 1, all 1s, or some other specified value in a storage location, or otherwise causing a logic value of 1, all 1s, or some other specified value to be stored in a storage location; however, these terms are not intended to limit the embodiments to any particular logical convention, as any logical convention may be used within the embodiments.

[0115] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure as set forth in the claims.

Claims

1. A device for performance monitoring based on instruction blocks, comprising: Execution hardware, the execution hardware is used to execute multiple instructions; as well as Block-based sampling hardware: for identifying an instruction block based on a first branch instruction in the plurality of instructions and a second branch instruction in the plurality of instructions; as well as Used to collect performance information during execution of the instruction block.

2. The device according to claim 1, wherein: The block-based sampling hardware is used to identify the beginning of the instruction block in response to retirement of the first branch instruction.

3. The device as claimed in claim 2, wherein: The block-based sampling hardware is to identify an end of the instruction block in response to retirement of the second branch instruction.

4. The device according to claim 1, wherein: Collecting the performance information includes counting occurrences of a type of event.

5. The device according to claim 1, wherein: Gathering the performance information includes aggregating latency for a type of event.

6. The device according to claim 1, wherein: The performance information is intended to be collected into trace records.

7. The apparatus of claim 6, further comprising an instruction decoder, the instruction decoder being configured to decode the insert event instruction, wherein: In response to the insert event instruction, the block-based hardware is operable to insert a data structure into the trace record.

8. The device according to claim 7, wherein: The insert event instruction is used to indicate the handle of the data record.

9. The device according to claim 7, wherein: The insert event instruction is used to indicate an insertion point in the trace record.

10. The apparatus of claim 1, further comprising a storage location for storing an instruction event address.

11. The device of claim 10, wherein: The instruction event address is based on the call branch target.

12. The device of claim 11, wherein: The instruction event address is also based on an index associated with a parameter of the call branch target.

13. The device of claim 11, wherein: The block-based sampling hardware is further operable to trigger an update of the value profile in response to a match associated with a retirement of a call branch instruction.

14. A method for performance monitoring based on instruction blocks, comprising: identifying, by block-based sampling hardware, a block of instructions based on a first branch instruction in a plurality of instructions and a second branch instruction in the plurality of instructions; as well as Performance information is collected by the block-based sampling hardware during execution of the instruction block.

15. The method of claim 14, wherein: Identifying the block of instructions includes identifying a start of the block of instructions in response to retirement of the first branch instruction.

16. The method of claim 14, wherein: The performance information is collected into a trace record, and the method further includes inserting a data structure into the trace record in response to an insert event instruction.

17. The method of claim 14, further comprising: The value profile is updated in response to an instruction event address match associated with a retirement of a call branch instruction.

18. A system for instruction block-based performance monitoring, comprising: Telemetry systems; Execution hardware, the execution hardware is used to execute multiple instructions; as well as Block-based sampling hardware: for identifying an instruction block based on a first branch instruction in the plurality of instructions and a second branch instruction in the plurality of instructions; as well as Used to collect telemetry information from the telemetry system during execution of the instruction block.

19. The system of claim 18, wherein: The performance information is configured to be collected into a trace record, the system further comprising an instruction decoder configured to decode an insert event instruction, wherein the block-based hardware is configured to insert a data structure into the trace record in response to the insert event instruction.

20. The system of claim 18, further comprising a storage location for storing an instruction event address, wherein: The block-based sampling hardware is further operable to trigger an update of the value profile in response to a match associated with a retirement of a call branch instruction.

Images