Compiler-generated KILO-instructions deep runahead
Compiler-generated meta-data for identifying hyperblocks and prefetching instructions addresses inefficiencies in existing methods, enhancing processor performance by reducing frontend stalls and enabling deep runaheads.
Patent Information
- Application Number
- PCT/CN2024/109611
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-08-02
- Publication Date
- 2026-02-05
AI Technical Summary
Existing methods for reducing frontend stalls in processor pipelines are limited by branch capacity and prediction complications, leading to inefficiencies in prefetching instructions, especially for large and complex computer workloads.
A method involving compiler-generated meta-data to identify hyperblocks and prefetch instructions based on predicted program behavior, using a runahead process to extend prefetching depth while minimizing redundant computation.
Enables efficient prefetching of instructions, preventing frontend stalls and allowing for deep runaheads, thereby optimizing processor performance for large and complex workloads.
Smart Images

Figure CN2024109611_05022026_PF_FP_ABST
Abstract
Description
COMPILER-GENERATED KILO-INSTRUCTIONS DEEP RUNAHEADTECHNICAL FIELD
[0001] The present disclosure generally relates to computer program execution, and more particularly methods and apparatus for prefetching computer program instructions.BACKGROUND
[0002] The code footprint of modern computer applications or workloads, such as those of mobile applications or server workloads, often exceeds the capacities of L1-I caches or even higher levels of cache. When this happens, forthcoming instructions may not be ready to be fetched and fed to the processor pipeline during execution of the application or workload, which can cause the processor to wait and waste cycles while the cacheline is filled from memory. These stalls in the processor pipeline are known as frontend stalls because they occur in the frontend of the processor pipeline. Although code can be optimized to remove hotspots for frontend stalls, complexities in the code, long repeat cycles, or a flat code profile can stymie approaches to identify hotspots.
[0003] Available techniques for avoiding frontend stalls typically either implement a runahead in-hardware or prefetching in-software. In an in-hardware runahead, the hardware may try to predict the direction and targets of the next few, typically 8 to 16, instruction branches (referred to herein as ‘branches’ ) and may prefetch the corresponding instruction cachelines (I-cachelines) . These in-hardware runahead techniques are limited both by their branch capacity, with 8 to 16 branches typically translating to fewer than 100 instructions, and by complications in identifying and making predictions of branches with the available hardware. Typically, some temporally local branches cannot be held in the limited size of the branch target buffer (BTB) , which can cause some branches to never be identified by the hardware nor to have predictions made for them. Alternatively, with in-software prefetching, the compiler may inject instruction-prefetch (I-prefetch) instructions directly into the program executable so that impending I-cachelines are prefetched. Achieving the correct timing for in-software prefetching can be difficult because runtime events are not known at compile time. Furthermore, prefetching for return paths can be computationally expensive. Combining in-hardware runahead and in-software prefetching techniques can lead to wasteful redundancy and excessive instruction overhead.
[0004] Therefore, there is a need for methods and apparatus for reducing frontend stalls that obviate or mitigate one or more limitations of the prior art.
[0005] This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.SUMMARY
[0006] An object of embodiments of the present disclosure is to provide methods and apparatus for reducing frontend stalls.
[0007] A first aspect of the present disclosure is to provide a method to be performed at an electronic device including a processing unit coupled to one or more tangible, processor-readable memory caches. The method may comprise obtaining, for one instruction of a plurality of instructions belonging to a computer program, an initial target instruction representing a start for a runahead process. The one instruction of the plurality of instructions may represent a branch in the computer program, and the plurality of instructions may define a plurality of basic blocks (BBs) . The method may further comprise loading, into a directory, program meta-data identifying one or more hyperblocks (HBs) for the computer program, with each HB encompassing, from among the plurality of BBs, a respective series of BBs having therebetween threshold transitions. Each threshold transition may have associated thereto a respective likelihood meeting a same pre-determined threshold. The program meta-data may further identify, for each HB, a respective one or more cache-line addresses corresponding to the respective series of BBs. The method may further comprise defining a current HB in accordance with the initial target instruction and executing, for one or more iterations, a set of runahead actions. The set of runahead actions may include: consulting the meta-data in the directory to obtain for the current HB the respective one or more cache-line addresses; pushing, when the respective one or more cache-line addresses for the current HB are obtained, the respective one or more cache-line addresses for the current HB to a prefetching element at the processing unit; and re-defining the current HB in accordance with a target instruction of the current HB. The method may still further comprise prefetching, to at least one of the one or more memory caches, the instructions of each BB of the respective series of BBs corresponding to each of the one or more cache-line addresses pushed to the prefetching element.
[0008] In some embodiments of the first aspect, the method may further comprise executing one or more instructions of the plurality of instructions belonging to the computer program to produce a corresponding one or more committed instructions, and evaluating the one or more committed instructions to identify the one instruction of the plurality of instructions as representing the branch in the computer program.
[0009] In some embodiments of the first aspect, the set of runahead actions may further include maintaining, in accordance with the meta-data in the directory, a return-address stack. In some of these embodiments, re-defining the current HB in accordance with the target instruction of the current HB may include consulting the return-address stack to obtain the target instruction of the current HB.
[0010] In some embodiments of the first aspect, the set of runahead actions may further include loading, into the directory, when the respective one or more cache-line addresses for the current HB are not obtained by consulting the meta-data in the directory, further meta-data identifying the current HB and the respective one or more cache-line addresses. In some of these embodiments, the current HB may have associated thereto a respective program counter, and loading, into the directory, the further meta-data may include applying a hash function to the respective program counter of the current HB to produce a respective hashed counter for the current HB and adding the respective hashed counter for the current HB to a base pointer to obtain a memory address for the further meta-data.
[0011] In some embodiments of the first aspect, the one instruction of the plurality of instructions may be either a call instruction or a return instruction. In some embodiments, the meta-data may further identify, for each of the one or more HBs, a respective program counter and a respective HB type. In some of these embodiments, the respective HB type for at least one of the one or more HBs indicates a call HB type. In some of these embodiments, the meta-data may further identify, for each of the at least one of the one or more HBs, a respective most-likely next HB and a respective return address. In some other embodiments, the respective HB type for at least one of the one or more HBs may indicate a return HB type.
[0012] In some embodiments of the first aspect, the one or more memory caches may include a L1-I cache and an L2 cache. In some embodiments, the meta-data may be loaded into the directory from tangible, processor-readable memory coupled to the electronic device.
[0013] In some embodiments of the first aspect, the meta-data may further identify, for each of at least one of the one or more HBs, a respective one or more additional cache-line addresses corresponding to the series of BBs for a respective one or more other HBs being respective targets of the respective HB. In some of these embodiments, the meta-data may further identify, for each of the at least one of the one or more HBs, a respective number of HBs representing the respective HB and the respective one or more other HBs.
[0014] In some embodiments of the first aspect, the computer program and the meta-data may each belong to a same extended executable. In some of these embodiments, the meta-data may be embedded in the computer program.
[0015] In some embodiments of the first aspect, the prefetching element includes at least one of a load-store unit and an instruction-fetch unit. In some of these embodiments, the prefetching element may further include a prefetch buffer. In some embodiments, the method may further comprise removing, by the prefetch buffer, at least one of the one or more cache-line addresses pushed to the prefetching element, with the at least one cache-line address being a duplicate of one other cache-line address of the one or more cache-line addresses pushed to the prefetching element.
[0016] In some embodiments of the first aspect, the same pre-determined threshold may be adjustable. In some other embodiments, the same pre-determined threshold may be fixed. In some embodiments, the same pre-determined threshold may be about 80%.
[0017] In some embodiments of the first aspect, the one or more iterations may include at least 50 iterations.
[0018] A second aspect of the present disclosure is to provide an electronic device comprising a processing unit coupled to one or more tangible, processor-readable memory caches, with the processing unit configured to perform the method according to the first aspect and any of its embodiments.
[0019] A third aspect of the present disclosure is to provide a method to be performed at an electronic device including a processor coupled to tangible, processor-readable memory. The method may comprise receiving a computer program including a plurality of instructions defining a plurality of basic blocks (BBs) , and profiling the computer program to identify a plurality of transitions each between a respective pair of BBs, with each transition representing a branch in the computer program. The method may further comprise demarcating a plurality of hyperblocks (HBs) for the computer program, with each HB encompassing, from among the plurality of BBs, a respective series of BBs having therebetween threshold transitions. Each threshold transition may be one transition of the plurality of transitions having associated thereto a respective likelihood meeting a same pre-determined threshold. The method may still further comprise providing meta-data for the computer program, with the meta-data identifying the plurality of HBs and, for each HB, a respective one or more cache-line addresses corresponding to the respective series of BBs.
[0020] In some embodiments of the third aspect, the method may further comprise determining, for each of one or more HBs of the plurality of HBs, a respective most-likely successor (MLS) in accordance with the respective likelihood of the plurality of transitions. In these embodiments, the meta-data may further identify, for each of the one or more HBs of the plurality of HBs, the respective MLS. In some embodiments, the method may further comprise detecting, between each pair of HBs of at least one pair of HBs from among the one or more HBs, a respective transition loop representing, in the computer program, at least one repetition of a respective one transition of the plurality of transitions. The respective one transition, for each pair of HBs of the at least one pair of HBs, may be between the respective series of BBs of each HB of the respective pair of HBs. In these embodiments, determining, for each of the one or more HBs of the plurality of HBs, the respective MLS may include determining, for each of a respective one HB of each pair of HBs of the at least one pair of HBs, the respective MLS in accordance with the respective transition loop, with the respective one HB of each pair of HBs succeeding, in the computer program, the other HB of the respective pair of HBs. In some other embodiments, the method may further comprise detecting, between each pair of HBs of at least one pair of HBs from among the one or more HBs, a respective one or more large call-stacks each including a plurality of HBs from among the plurality of HBs. In these embodiments, determining, for each of the one or more HBs of the plurality of HBs, the respective MLS may include determining, for each of a respective one HB of each pair of HBs of the at least one pair of HBs, the respective MLS in accordance with the respective one or more large call-stacks, with the respective one HB of each pair of HBs preceding, in the computer program, the other HB of the respective pair of HBs.
[0021] In some embodiments of the third aspect, the meta-data may further identify, for each HB of the plurality of HBs, a respective program counter and a respective HB type. In some of these embodiments, the respective HB type for at least one HB of the plurality of HBs may indicate a call HB type. In these embodiments the meta-data may further identify, for each HB of the plurality of HBs, a respective most-likely next HB and a respective return address. In some other embodiments, the respective HB type for at least one HB of the plurality of HBs may indicate a return HB type.
[0022] In some embodiments of the third aspect, the meta-data may further identify, for each of at least one HB of the plurality of HBs, a respective one or more additional cache-line addresses corresponding to the series of BBs for a respective one or more other HBs being respective targets of the respective HB. In some of these embodiments, the meta-data may further identify, for each of the at least one HB of the plurality of HBs, a respective number of HBs representing the respective HB and the respective one or more other HBs.
[0023] In some embodiments of the third aspect, the same pre-determined threshold may be adjustable. In some other embodiments, the same pre-determined threshold may be fixed. In some embodiments, the same pre-determined threshold may be about 80%.
[0024] A fourth aspect of the present disclosure is to provide an electronic device comprising a processor coupled to tangible, processor-readable memory, with the processor configured to perform the method according to the third aspect and any of its embodiments.
[0025] Embodiments of the present disclosure may facilitate efficient prefetching of instructions for computer programs. Some embodiments may enable deep runaheads for predicting program behaviour. This may prevent frontend stalls in a processor pipeline.
[0026] Embodiments have been described above in conjunction with aspects of the present disclosure upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.BRIEF DESCRIPTION OF THE DRAWINGS
[0027] FIG. 1 shows a schematic of an example of a call stack, towards which embodiments of the present disclosure may be implemented.
[0028] FIG. 2 shows a flowchart of a method for profiling and analyzing a computer program in accordance with embodiments of the present disclosure.
[0029] FIG. 3 shows a schematic of an example of hyperblocks, in accordance with an embodiment of the present disclosure.
[0030] FIG. 4 shows a schematic for a runahead process in accordance with embodiments of the present disclosure.
[0031] FIG. 5 shows a schematic for loading meta-data for a runahead in accordance with embodiments of the present disclosure.
[0032] FIG. 6 shows a flowchart of a method for a runahead in accordance with an embodiment of the present disclosure.
[0033] FIG. 7 shows an example of a call stack with runaheads, in accordance with an embodiment of the present disclosure.
[0034] FIG. 8A shows an example of a cycle between hyperblocks, towards which embodiments of the present disclosure may be implemented.
[0035] FIG. 8B shows an example for cycle removal, in accordance with an embodiment of the present disclosure.
[0036] FIG. 9 shows a flowchart of a method for cycle removal, in accordance with embodiments of the present disclosure.
[0037] FIG. 10A shows an example of large call stacks between hyperblocks, towards which embodiments of the present disclosure may be implemented.
[0038] FIG. 10B shows an example of large call stack removal, in accordance with an embodiment of the present disclosure.
[0039] FIG. 10C shows another example of large call stack removal, in accordance with another embodiment of the present disclosure.
[0040] FIG. 11 shows a schematic of an apparatus for a runahead process according to embodiments of the present disclosure.
[0041] FIG. 12 shows a schematic of an embodiment of an electronic device that may implement at least part of the methods and features of the present disclosure.DETAILED DESCRIPTION
[0042] To avoid frontend stalls in the processor pipeline when executing a computer program, embodiments of the present disclosure are generally directed towards providing a runahead process for prefetching instructions from the computer program. The computer program may, for example, be a server workload or a mobile application, which may have a large and / or complex code footprint. In embodiments, a compiler may profile the computer program, either offline or online, to obtain meta-data on the computer program. The meta-data may define, for the computer program, a call graph as well as hyperblocks (HBs) and transitions between them. HBs may represent a series of basic blocks (BBs) wherein the transitions between them have a likelihood that meets a certain threshold. A processor may execute the computer code and pass committed instructions to a runahead processing unit. Instructions representing branches, such as calls or returns, may initiate a runahead process. The runahead processing unit, using the meta-data, may determine a target HB for the branch and begin identifying I-cacheline addresses corresponding to the target HB and subsequent target HBs. These I-cacheline address may be prefetched to avoid frontend stalls. In some embodiments, the meta-data may be held in a cached table at the runahead processing unit and may be updated throughout the runahead process. A return-address stack may further be maintained to keep track of the call stack and may be consulted during the runahead process. In some embodiments, cycles and / or large call stacks may be removed from the meta-data to enable deep runaheads. Embodiments of the present disclosure may enable runaheads on the order of a thousand instructions (i.e., kilo-level or deep runaheads) .
[0043] The present disclosure sets forth various embodiments via the use of block diagrams, flowcharts, and examples. Insofar as such block diagrams, flowcharts, and examples contain one or more functions and / or operations, it will be understood by a person skilled in the art that each function and / or operation within such block diagrams, flowcharts, and examples can be implemented, individually or collectively, by a wide range of hardware, software, firmware, or combination thereof. As used herein, the term “about” should be read as including variation from the nominal value, for example, a + / -10%variation from the nominal value. It is to be understood that such a variation is always included in a given value provided herein, whether or not it is specifically referred to. The terms in each of the following sets may be used interchangeably throughout the disclosure: “branch” and “call or return instruction” ; “run” and “execute” ; “compiler” and “binary optimizer” ; “commit” and “retire” ; “computer program” , “mobile application” , and “server workload” ; and “runahead logic unit” and “runahead control unit” .
[0044] FIG. 1 shows an example of a typical call stack for a computer program. A caller function f () 100 of the computer program, having a first partition P1, calls 101 (depicted by filled arrows) a series of functions 102 such as g () , h () , and a further call stack 103. A return path 104 makes returns 104 (depicted by unfilled arrows) through the series of functions 102 to a second partition P2 of the caller function f () 100, which defines a return path 105. Prefetching instructions for the depicted call stack using available methods can be difficult and ineffective in preventing frontend stalls. For example, in available methods for in-software prefetching, wherein a compiler may inject I-prefetch instructions directly into the computer program executable so that forthcoming I-cachelines are prefetched, prefetching along the return path 105, such as for the second partition of the caller function f() 100, can be computationally expensive because the address for that partition needs to be calculated by obtaining multiple values from the call stack.
[0045] Embodiments of the present disclosure may generally be directed towards reducing frontend stalls by enabling prefetching that extends further into the future while avoiding excessive instruction overhead and computation. In prefetching, embodiments may use a combination of software and hardware aspects connected through a software-to-hardware interface. In embodiments, a compiler may predict computer program behaviour at high levels and large scales by analyzing the control flow of the computer program. This may form most-likely path information for the computer program that can be passed as meta-data to the hardware for program execution. In particular, the meta-data may be loaded to memory, where the hardware may access it via a system register and use, during execution, the meta-data to speculatively prefetch future instruction cache-lines. The most-likely path information may comprise a series of HBs and a runahead depth may be defined according to a number of HBs that may be chained for prefetching.
[0046] FIG. 2 shows a flowchart for a method for profiling a computer program in accordance with embodiments of the present disclosure. The method may be performed, for example, by a compiler or a binary optimizer. At action 201, the computer program may be received. The program may comprise a plurality of instructions and may, for example, be a server workload or a mobile application. At action 202, the computer program may be profiled, either online or offline. Profiling may include identifying BBs within the computer program. Each BB may be a series of instructions in the computer program that may only be entered at a first instruction of that BB and may only branch at a last instruction of that BB. A branch may, for example, be a call or return instruction. Each BB may, for example, include about five instructions. Profiling may further include identifying the transitions among the BBs and developing call-graph information. The transitions between pairs of BBs may therefore be branches in the computer program.
[0047] At action 203, the results of the profiling may be analyzed to produce, at action 204, a call graph providing the sequence of function calls in the computer program and may be analyzed to further produce, at action 205, a chain of HBs. The analysis may include demarcating a plurality of HBs for the computer program and then chaining them according to the transitions among BBs. The plurality of HBs may be demarcated by considering the likelihood of transitions among the BBs (i.e., the probability for that transition to happen) , which may be determined in the analysis. An HB may include a series of BBs wherein the transitions between those BBs have likelihoods that meet a certain threshold (i.e., the transitions are ‘threshold transitions’ ) . In other words, transitions with likelihoods not meeting the threshold may be the demarcations between HBs. The threshold may be a same pre-determined value that each transition between BBs is evaluated against. For example, if the threshold were set to a likelihood of 80%, the transitions between BBs in each HB may need to be above 80%, or, alternatively, equal to or above 80%. Meeting the threshold may include equaling and / or exceeding the threshold. In some embodiments, the threshold may be adjustable. Each HB may, for example, include about four BBs, which may be expanded to about eight to ten BBs with merging. The analysis performed at action 203 may further include identifying most-likely successors (MLSs) for each HB. Each HB may branch to one or more subsequent HBs, and each of those branches may have a particular transition likelihood; the MLS for an HB may be the subsequent HB that is entered through the branch having the greatest transition likelihood. The analysis may still further include identifying cycles and / or large stacks in the call flow and determining each MLS around these (described further hereinbelow) . The results of the method may be provided as meta-data for the computer program.
[0048] FIG. 3 shows a schematic for an example of BBs and HBs in a computer program, in accordance with embodiments of the present disclosure. The computer program includes a first function f () 301 (the ‘caller’ ) that calls a second function g () 302 (the 'callee’ ) . Each of the first function 301 and the second function 302 include a respective plurality of BBs 303 (depicted as square boxes and labelled by numbers) . The BBs 303 are interconnected by transitions (indicated by filled arrows) each having a respective likelihood 304 associated thereto (indicated by adjacent numerical values) . For example, the ninth BB 303 of the first function 301 has a 10%likelihood 304 of being reached from the second BB 303 of that same function. Each series of BBs 303 having threshold transitions forms a respective HB 305 (indicated by dotted lines) . In this example, the threshold is 80%. Although multiple HBs 305 may terminate at a same BB 303, no two HBs 305 begin at the same BB 303. For example, three HBs 305 in the first function 301 respectively start at the first BB 303, the eighth BB 303, and the ninth BB 303, and all end at the seventh BB 303. The second function 302 is reached through a call 306 between the seventh BB 303 of the first function 301 and the first BB 303 of the second function 302. The second function 302 then returns to the first function 301 through a return 307 between the fourth BB 303 of the second function 302 to the tenth BB 303 of the first function 301. The tenth BB 303 of the first function 301 may alternatively be reached through another return 308 from the seventh BB 303 of the first function 301. FIG. 3 further shows an example of an MLS 309 (indicated by dotted arrow) for one of the HBs 305, where the transition likelihoods 304 are 30%and 70%to two subsequent HBs 305.
[0049] FIG. 4 shows a schematic for performing a runahead, in accordance with embodiments of the present disclosure. A compiler 401, or alternatively a binary optimizer, may be configured to perform the method described in relation to FIG. 2 for a computer program. The compiler 401 may produce meta-data that may be added to a binary executable for the computer program to form an extended executable and linkable format (ELF) file 402. When executing the extended ELF by a processing device, the meta-data 403 may be loaded, such as by a loader in the operating system for the processing device, to a memory region in virtual memory address space 404 associated with the processing device. The computer program may also be loaded into memory, such as by the loader, and may be run (or executed) by a processor core 405 at the processing device. The computer program may include one or more threads 406 each defining a respective sequence of HBs 305. As the program runs and commits instructions thereof, a commit unit 407 at the processor core 405 may provide the respective program counter (PC) for each committed instruction to a deep runahead unit 408.
[0050] The deep runahead unit 408 may be a processing unit within the processor core 405 that is configured to perform the runahead. When receiving a PC for a committed instruction, the deep runahead unit 408 may evaluate that committed instruction to identify whether it represents a branch, such as a call or return. If a committed instruction does represent a branch, the deep runahead unit 408 may “pick” 409 or select that instruction for proceeding with the runahead. The deep runahead unit 408 may then obtain 410 a PC corresponding to a target of the branch. This PC may be considered the initial target instruction for the runahead process and may further define a current HB 305 for the runahead. The PC for the initial target instruction may be passed to a runahead logic unit 411 or runahead control unit. The runahead logic unit 411 may execute a set of runahead actions for N iterations to determine, for a predicted forthcoming chain of HBs 305 from the initial target instruction, instructions that should be prefetched. N may be a natural number and referred to as the “runahead depth” . The runahead depth may be a fixed, pre-determined number or, alternatively, may adjust automatically during execution of the computer program. Adjustments may be made, for example, in accordance with a miss-rate for fetches as the computer program executes.
[0051] The set of runahead actions may include consulting a directory 412 (i.e., the “cached HB-table” ) at the deep runahead unit 408 that is used to store a cache of the meta-data 403 on the computer program. The directory 412 may be loaded with meta-data 403 according to a process described hereinbelow. The meta-data 403 in the directory 412 may be consulted in accordance with the PC corresponding to the current HB 305. The directory 412 may provide meta-data 403 for the current HB that identifies, for the current HB 305, one or more cache-line addresses ( “I-prefetch addresses” ) corresponding to the respective series of BBs 303. These cache-line addresses may be obtained by the deep runahead unit 408 when consulting the directory 412. The directory 412 may hold a cache of meta-data for other HBs 305, beyond the current HB 305, that has been recently loaded for runahead calculations. In some embodiments, the meta-data 403 in the directory 412 may further identify, for the current HB 305 (as provided by its PC) , an HB type. The HB type may indicate, for example, that the current HB 305 is one of a call, a return, or other type. The HB type for an HB 305 may depend from the last instruction of the last BB 303 of the respective series of BBs 303. When the current HB 305 is indicated as a call, the meta-data 403 in the directory 412 may further identify a respective most-likely next HB 305 ( “nHB” or “next-HB” ) or MLS 309 along with a respective return address ( “RetAddr” ) .
[0052] The set of runahead actions may further include maintaining, in accordance with the meta-data 403 in the directory 412, a return-address stack (RAS) 413. The RAS 413 may be used to keep track of the call stack during execution of the computer program. Maintaining the RAS 413 may include maintaining a temporary runahead stack (i.e., a “runahead_RAS” ) on top of the RAS 413 that is updated for each set of runahead actions. When the current HB 305 is indicated as a call by the meta-data 403 in the directory 412, the respective return address in the directory 412 may be pushed onto the temporary runahead stack. When the current HB 305 is indicated as a return by the meta-data 403 in the directory 412, a respective return address may be popped from the temporary runahead stack.
[0053] The set of runahead actions may further include re-defining the current HB 305 according to a target instruction of the current HB 305. In this way, future or forthcoming HBs 305 may be mapped or chained from the initial target instruction through the N iterations. The target instruction of the current HB 305 may be obtained, for example, by consulting the RAS 413 when the current HB 305 is indicated as a return by the meta-data 403 in the directory 412. Alternatively, the target instruction of the current HB 305 may be determined according to the respective most-likely next HB 305 identified by the meta-data in the directory 412.
[0054] While the set of runahead actions is performed for N iterations and while HBs 305 are mapped, a plurality of cache-line addresses may be obtained by the deep runahead unit 408. The set of runahead actions may further include pushing each cache-line address that is obtained to a prefetching element at the processor core 405. The prefetching element may include a load-store unit or instruction fetch unit 414, which may prefetch, to at least one of one or more memory caches, the instructions of each BB 303 of the respective series of BBs 303 corresponding to each of the cache-line addresses. The prefetching element may further include a prefetch buffer 415, which may inspect the cache-line addresses pushed from the deep runahead unit 408 and remove any duplicate cache-lines addresses before passing them to the load-store unit or instruction fetch unit 414. The prefetch buffer 415 may pass the cache-line addresses to the load store unit or instruction fetch unit 414 gradually. The one or more memory caches may include, for example, an L1-I cache 416 or an L2 cache 417. The prefetched instructions may then be readily fetched for program execution. In some embodiments, the instructions of each BB 303 of the respective series of BBs 303 corresponding to each of the cache-line addresses may additionally be pre-decoded and preloaded to a branch target buffer (BTB) , thereby providing the BTB with the predicted targets of branches and improving performance.
[0055] FIG. 5 shows a schematic for loading meta-data 403 to the directory 412 at the deep runahead unit 408, in accordance with embodiments of the present disclosure. Meta-data 403 on an HB may be loaded to the directory 412 when it is not already present. In other words, if the runahead logic unit 411 consults the directory 412 and encounters a miss for the PC corresponding to the current HB 305, the meta-data entry for the current HB 305 may be loaded from memory. To obtain the address of the meta-data entry in memory, a hash function 501 may be applied to the PC corresponding to the current HB 305, and the results (i.e., a hashed counter) may be added to a base pointer of a system register ( “HBT_PTR” ) 502 that points to the virtual memory address space 404 for the meta-data 403. The meta-data 403 stored in memory may comprise a full list 503 of entries for all of the HBs 305 for the computer program, from which the one desired meta-data entry 504 may be loaded.
[0056] FIG. 6 shows a flowchart of a method for a deep runahead, in accordance with embodiments of the present disclosure. At action 601, a computer program is received. At action 602, the computer program may be profiled and the control flow may be analyzed to obtain meta-data 403 identifying a plurality of HBs 305 and one or more cache-line addresses for each, as described above in relation to FIG. 2. At action 603, the meta-data 403 may be loaded into memory. At action 605, one or more threads 406 of the computer program may be executed, such as by a processor core 405. Committed instructions may be obtained, at action 605, and those that are branches, such as calls 101 or returns 104, may be identified and selected, at action 606, for a deep runahead process 607 performed by a deep runahead unit 408. At action 608, the PC of the target for each selected branch instruction may be obtained to serve as the initial target instruction. At action 609, a chain of HBs 305 may be mapped from the target PC to form a predicted path of instructions to prefetch. Cache-line addresses may be obtained for the chain of HBs 305. Chaining the HBs 305 and obtaining the cache-line addresses may include consulting a RAS 413 for return addresses and consulting a directory 412 with cached meta-data 403. At action 610, meta-data 403 may be loaded from memory to the directory 412, such as when a miss occurs when consulting the directory 412. At action 611, the RAS 413 may be maintained, such as by pushing or popping a return address to or from a temporary runahead stack at the RAS 413. At action 612, the cache-line addresses may be pushed to a prefetching element. At action 613, the cache-line addresses may be inspected for duplicates and any found may be removed. At action 614, the instructions corresponding to the remaining cache-line addresses may be prefetched to one or more memory caches for fetching during program execution.
[0057] FIG. 7 shows an example of a call stack in a computer program for which embodiments of the present disclosure may be implemented. The call stack comprises a series of nine HBs 305 with transitions that are either calls 101 (indicated by filled arrows) or returns 104 (indicated by unfilled arrows) . In accordance with embodiments of the present disclosure, the three dashed arrows indicate the depth 701 of a runahead process for three different initial target HBs (HB2, HB3 and HB4) , where N = 3. For example, when the first HB 305 (HB1) is committed, the next HB 305 in the call stack would be the initial target (HB2) and the runahead process would proceed through the next three HBs 305 (until HB5) . In such a case, cache-lines corresponding to those four HBs (HB2, HB3, HB4, and HB5) may be prefetched. In another example, when the second HB 305 (HB2) is committed, the RAS may be consulted to facilitate the transition in the runahead process between the fifth HB 305 (HB5) and the sixth HB 305 (HB6) .
[0058] Table 1, provided below, shows an example of a directory 412 with meta-data entries in accordance with the example call stack shown in FIG. 7 and further in accordance with one embodiment of the present disclosure. In addition to identifying, for each HB 305, one or more cache-line addresses ( “I-prefetch addresses” ) corresponding to the respective series of BBs 303, the directory 412 identifies, for each HB 305, an HB type and further, for calls, a next HB and a return address.
[0059] Table 2, also provided below, shows another example of a directory 412 with meta-data entries in accordance with the example call stack shown in FIG. 7 and further in accordance with another embodiment of the present disclosure. Here, the directory 412 identifies, for each HB 305, one or more cache-line addresses ( “I-prefetch addresses” ) corresponding to the respective series of BBs 303 along with, for each of some of the HBs 305, the cache-line addresses corresponding to the series of BBs 303 for one or more other HBs 305 anticipated for the runahead process for the respective HB 305. The directory 412 further identifies the number of other HBs 305 anticipated for the runahead process (i.e., the “length” ) . The meta-data 403 in Table 2 may be used towards a semi-static runahead, wherein at least a portion of the runahead may have been performed when profiling 202 and analyzing 203 the computer program at a compiler 401 or binary optimizer instead of during program execution. In the example of FIG. 7, the runahead for the second HB 305 (HB2) may be statically determined during profiling, whereas the runahead for the fifth HB 305 (HB5) may only be determined during execution because the callers for the sixth HB 305 (HB6) and the seventh HB 305 (HB7) would not be known and would need to be obtained from the RAS 413. Hence, this runahead process may be referred to as being semi-static. For execution, the set of runahead actions may include modifying the runahead depth in accordance with the length provided by the meta-data entry for the current HB 305.
[0060] Table 1. First example of a cached meta-data directory.
[0061] Table 2. Second example of a cached meta-data directory.
[0062] FIG. 8A shows a schematic of an example of a cycle in a computer program, towards which embodiments of the present disclosure may be implemented. Cycles in a computer program may arise from loops or recursion. Here, a first HB 305 (HB1) calls a second HB 305 (HB2) , which in turn calls a third HB 305 (HB3) . The third HB 305 has a 10%likelihood 304 of calling a fourth HB 305 (HB4) and a 90%likelihood 304 of calling the second HB 305 again, creating a cycle 801. The first HB 305 encompasses about 10 instructions and the second and third HBs 305 encompass about 20 instructions together. In executing the first to third HBs 305, about 200 instructions may be expected to be executed because of the likelihood for entering the cycle 801.
[0063] Embodiments of the present disclosure may remove each cycle 801 from the meta-data 403 to prevent the runahead from becoming stuck in each cycle 801 and to enable the runahead to achieve a greater depth. To remove cycles, the next-HB or MLS 309 may be modified in the meta-data 403. FIG. 8B shows a schematic for removing cycles 801 in accordance with an embodiment of the present disclosure and the example shown in FIG. 8A. Here, the transition causing the cycle 801 is removed (indicated by dashed arrow) , enabling the runahead to proceed through to the fourth HB 305.
[0064] FIG. 9 shows a flowchart of a method for removing cycles 801, in accordance with embodiments of the present disclosure. During profiling 202 and analysis 203 of a computer program, a cycle 801 between an ith HB 305 (HBi) and a jth HB (HBj) may be detected. The cycle 801 may be defined by a transition between a pair of HBs 305 (e.g., HBi and HBj) that repeats within the computer program (i.e., a “transition loop” ) . At action 901 of FIG. 9, a set ( “CycleHBs” ) of all the HBs 305 involved in the cycle 801 ( “HBcs” ) may be defined. At action 902, all the HBs between each call and its matching return in CycleHBs may be removed from the set to simplify and / or shorten the cycle 801. Then, for each remaining HBc in CycleHBs: a respective set of all post-dominator HBs (PDOMHBc) may be defined, at action 903; a respective immediate post-dominator HB (IPDOMHBc) may be defined, at action 904; and the IPDOMHBc may be added to a set for IPDOMs, at action 905. The post-dominator HBs for each HBc may be the HBs that execute after the respective HBc. The immediate post-dominator for each HBc may be the HBc that executes immediately afterwards. At action 906, the intersection (HBk) of all the PDOMHBc sets and the set of IPDOMs may be determined. At action 907, the next-HB or MLS 309 for HBi may be set to HBk. In other words, the MLS 309 may be determined in accordance with the transition loop and cycle 801.
[0065] FIG. 10A shows a schematic of an example of large call stacks in a computer program, towards which embodiments of the present disclosure may be implemented. A first HB 305 (HB1) indirectly calls a second HB 305 (HB2) through a call 101 (indicated by filled arrows) to one of three large call stacks 1001 (call stacks 1, 2, and 3) that return 104 (indicated by unfilled arrows) to the second HB 305. Each call stack 1001 has an associated likelihood 304 for being called: 50%for call stack 1, 30%for call stack 2, and 20%for call stack 3. Each call stack 1001 may include, for example, a plurality of HBs 305 and hundreds of instructions.
[0066] Embodiments of the present disclosure may remove or skip over call stacks in the meta-data 403 to predict future paths and enable the runahead to achieve greater depth. Embodiments may detect the large call stacks during profiling 202 and analysis 203 of the computer program. In one embodiment, shown by a schematic in FIG. 10B, the call stack with the greatest likelihood 304 (call stack 1) may be chosen for the runahead and the other call stacks (call stacks 2 and 3) may be removed (indicated by dashed arrows and lines) . Alternatively, in another embodiment, shown by a schematic in FIG. 10C, each of the call stacks 304 may be removed and the next-HB or MLS 309 may be determined such that the runahead skips the call stacks 304. In other words, the MLS 309 may be determined in accordance with the one or more large call stacks.
[0067] In embodiments of the present disclosure, meta-data 403 may be loaded from memory to a cached directory 412 when a miss occurs when consulting the directory 412 during the runahead process. In some other embodiments, the directory 412 may be updated periodically or occasionally with batches of meta-data 403 loaded from memory. This may be done, for example, when the execution reaches a new phase or stage in the computer program. In some other embodiments, each HB 305 in the computer program may be instrumented with its corresponding meta-data 403, so that the directory may be updated when the respective HB 305 is fetched. In other words, the meta-data 403 may be embedded in-line in the code of the computer program.
[0068] In embodiments of the present disclosure, the runahead process may chain HBs 305 in accordance with their next-HB or MLS 309. In some other embodiments, a plurality of chains or paths of HBs 305 may be determined from an initial target instruction. In this case, cache-line addresses may be pushed to the prefetching element for each of the chains of HBs 305 and all the corresponding instructions may be prefetched. In some other embodiments, the runahead process may chain HBs 305 according to call-context information deriving from the stack of previously called program functions.
[0069] Embodiments of the present disclosure may be implemented using electronics hardware, software, or a combination thereof. Some embodiments may be implemented by one or multiple computer processors executing program instructions stored in memory. Some embodiments may be implemented partially or fully in hardware, for example, using one or more field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs) to rapidly perform processing operations.
[0070] FIG. 11 shows an apparatus 1100 for implementing, at least partly, methods for compiling and / or performing a deep runahead process according to embodiments of the present disclosure. The apparatus 1100 may be located at a network element 1110 of a communication network. The apparatus 1100 may include a network interface 1120 and processing electronics 1130. The processing electronics 1130 may include a computer processer executing program instructions stored in memory, or other electronics components such as digital circuitry, including, for example, FPGAs and ASICs. The network interface 1120 may include an optical communication interface or radio communication interface, such as a transmitter and receiver. The apparatus 1100 may include several functional components, each of which may be partially or fully implemented using the underlying network interface 1120 and processing electronics 1130. Examples of functional components may include modules for profiling 1140 a computer program, generating 1141 meta-data for a computer program, identifying 1142 branch program instructions, mapping 1143 future paths for program instructions, and prefetching 1143 instructions to cache memory units.
[0071] FIG. 12 is a schematic diagram of an electronic device 1200 that may perform any or all of the operations of the above methods and features explicitly or implicitly described herein, according to different embodiments of the present disclosure. For example, a computer equipped with network functions may be configured as electronic device 1200. The electronic device 1200 may, for example, be used as or as part of the processor core 405, as described in relation to FIG. 4.
[0072] As shown, the electronic device 1200 includes a processor 1210, such as a Central Processing Unit (CPU) or specialized processors such as a Graphics Processing Unit (GPU) or other such processor unit, memory 1220, and a bi-directional bus 1230 to communicatively couple the components of electronic device 1200. Electronic device 1200 may also optionally include a network interface 1240, non-transitory mass storage 1250, an I / O interface 1260, and a transceiver 1270. According to certain embodiments, any or all of the depicted elements may be utilized, or only a subset of the elements. Furthermore, the device 1200 may contain multiple instances of certain elements, such as multiple processors, memories, or transceivers. In addition, elements of the hardware device may be directly coupled to other elements without the bi-directional bus. Additionally or alternatively to a processor 1210 and memory 1220, other electronics, such as integrated circuits, may be employed for performing the required logical operations. The processor 1210 may include the deep runahead unit 408, as described in relation to FIG. 4
[0073] The memory 1220 may include any type of tangible, non-transitory memory such as static random access memory (SRAM) , dynamic random access memory (DRAM) , synchronous DRAM (SDRAM) , read-only memory (ROM) , any combination of such, or the like. Memory 1220 may include more than one type of memory, such as ROM for use at boot-up, and DRAM for program and data storage for use while executing programs. The memory 1220 may further include the one or more memory caches and / or the memory space to which meta-data 403 may be loaded. The mass storage element 1250 may include any type of tangible, non-transitory storage device, such as a solid state drive, hard disk drive, a magnetic disk drive, an optical disk drive, USB drive, or any computer program product configured to store data and machine executable program code. According to certain embodiments, the memory 1220 or mass storage 1250 may have recorded thereon statements and instructions executable by the processor 1210 for performing any of the aforementioned method operations described above. In some embodiments, mass storage 1250 may be remote to the electronic device 1200 and accessible through use of a network interface such as interface 1230. In the embodiment of FIG. 12, mass storage 1250 is distinct from memory 1220 and may generally perform storage tasks compatible with higher latency but may generally provide lesser or no volatility. In some embodiments, mass storage 1250 may be integrated with the memory 1220.
[0074] The bi-directional bus 1240 may be one or more of any type of several bus architectures, including a memory bus or memory controller, a peripheral bus, or a video bus.
[0075] It will be appreciated that, although specific embodiments of the technology have been described herein for purposes of illustration, various modifications may be made without departing from the scope of the technology. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention. In particular, it is within the scope of the technology to provide a computer program product or program element, or a program storage or memory device such as a magnetic or optical wire, tape or disc, or the like, for storing signals readable by a machine, for controlling the operation of a computer according to the method of the technology and / or to structure some or all of its components in accordance with the system of the technology.
[0076] Acts associated with the method described herein may be implemented as coded instructions in a computer program product. In other words, the computer program product may be a computer-readable medium upon which software code may be recorded to execute the method when the computer program product is loaded into memory and executed on the microprocessor of the wireless communication device.
[0077] Further, each operation of the method may be executed on any computing device, such as a personal computer, server, PDA, or the like and pursuant to one or more, or a part of one or more, program elements, modules or objects generated from any programming language, such as C++, Java, or the like. In addition, each operation, or a file or object or the like implementing each said operation, may be executed by special purpose hardware or a circuit module designed for that purpose.
[0078] Embodiments of the present disclosure may be implemented by using hardware only or by using software and a necessary universal hardware platform. Based on such understandings, the technical solution of the present disclosure may be embodied in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which may be a compact disk read-only memory (CD-ROM) , USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided in the embodiments of the present disclosure. For example, such an execution may correspond to a simulation of the logical operations as described herein. The software product may additionally or alternatively include a number of instructions that enable a computer device to execute operations for configuring or programming a digital logic apparatus in accordance with embodiments of the present disclosure.
[0079] The word “a” or “an” when used in conjunction with the term “comprising” or “including” in the claims and / or the specification may mean “one” , but it is also consistent with the meaning of “one or more” , “at least one” , and “one or more than one” unless the content clearly dictates otherwise. Similarly, the word “another” may mean at least a second or more unless the content clearly dictates otherwise. The phrase "at least one" means one or more, and "a plurality of" means two or more. In addition, "and / or" describes an association relationship of associated objects, and indicates that there may be three relationships. For example, A and / or B may indicate cases including “only A” , “both A and B” , and “only B” , where A and B may be singular or plural. The character " / " generally indicates that the associated objects are in an OR relationship. "At least one of the following items" or a similar expression thereof refers to any combination of these items, including any combination of a single item or a plurality of items. For example, “at least one of a, b, or c” may represent “a” , “b” , “c” , “a and b” , “a and c” , “b and c” , or “a, b and c” , where a, b, and c may be a single or multiple form.
[0080] The terms “coupled” , “coupling” or “connected” as used herein can have several different meanings depending on the context in which these terms are used. For example, as used herein, the terms coupled, coupling, or connected can indicate that two elements or devices are directly connected to one another or connected to one another through one or more intermediate elements or devices via a mechanical element depending on the particular context. The term “and / or” herein when used in association with a list of items means any one or more of the items comprising that list.
[0081] Although a combination of features is shown in the illustrated embodiments, not all of them need to be combined to realize the benefits of various embodiments of this disclosure. In other words, a system or method designed according to an embodiment of this disclosure will not necessarily include all features shown in any one of the Figures or all portions schematically shown in the Figures. Moreover, selected features of one example embodiment may be combined with selected features of other example embodiments.
[0082] Although the present invention has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the invention. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention.
Claims
1.A method comprising, at an electronic device including a processing unit coupled to one or more tangible, processor-readable memory caches:obtaining, for one instruction of a plurality of instructions belonging to a computer program, an initial target instruction representing a start for a runahead process, the one instruction of the plurality of instructions representing a branch in the computer program, the plurality of instructions defining a plurality of basic blocks (BBs) ;loading, into a directory, program meta-data identifying one or more hyperblocks (HBs) for the computer program, each HB encompassing, from among the plurality of BBs, a respective series of BBs having therebetween threshold transitions, each threshold transition having associated thereto a respective likelihood meeting a same pre-determined threshold, the program meta-data further identifying, for each HB, a respective one or more cache-line addresses corresponding to the respective series of BBs;defining a current HB in accordance with the initial target instruction;executing, for one or more iterations, a set of runahead actions including:consulting the meta-data in the directory to obtain for the current HB the respective one or more cache-line addresses;pushing, when the respective one or more cache-line addresses for the current HB are obtained, the respective one or more cache-line addresses for the current HB to a prefetching element at the processing unit; andre-defining the current HB in accordance with a target instruction of the current HB; andprefetching, to at least one of the one or more memory caches, the instructions of each BB of the respective series of BBs corresponding to each of the one or more cache-line addresses pushed to the prefetching element.2.The method of claim 1 further comprising, at the electronic device:executing one or more instructions of the plurality of instructions belonging to the computer program to produce a corresponding one or more committed instructions; andevaluating the one or more committed instructions to identify the one instruction of the plurality of instructions as representing the branch in the computer program.3.The method of claim 1 wherein the set of runahead actions further includes:maintaining, in accordance with the meta-data in the directory, a return-address stack.4.The method of claim 3 wherein re-defining the current HB in accordance with the target instruction of the current HB includes:consulting the return-address stack to obtain the target instruction of the current HB.5.The method of claim 1 wherein the set of runahead actions further includes:loading, into the directory, when the respective one or more cache-line addresses for the current HB are not obtained by consulting the meta-data in the directory, further meta-data identifying the current HB and the respective one or more cache-line addresses.6.The method of claim 5 wherein:the current HB has associated thereto a respective program counter; andloading, into the directory, the further meta-data includes:applying a hash function to the respective program counter of the current HB to produce a respective hashed counter for the current HB; andadding the respective hashed counter for the current HB to a base pointer to obtain a memory address for the further meta-data.7.The method of claim 1 wherein the one instruction of the plurality of instructions is either a call instruction or a return instruction.8.The method of claim 1 wherein the one or more memory caches includes a L1-I cache and an L2 cache.9.The method of claim 1 wherein the meta-data is loaded into the directory from tangible, processor-readable memory coupled to the electronic device.10.The method of claim 1 wherein the meta-data further identifies, for each of the one or more HBs, a respective program counter and a respective HB type.11.The method of claim 10 wherein the respective HB type for at least one of the one or more HBs indicates a call HB type.12.The method of claim 11 wherein the meta-data further identifies, for each of the at least one of the one or more HBs, a respective most-likely next HB.13.The method of claim 11 wherein the meta-data further identifies, for each of the at least one of the one or more HBs, a respective return address.14.The method of claim 10 wherein the respective HB type for at least one of the one or more HBs indicates a return HB type.15.The method of claim 1 wherein the meta-data further identifies, for each of at least one of the one or more HBs, a respective one or more additional cache-line addresses corresponding to the series of BBs for a respective one or more other HBs being respective targets of the respective HB.16.The method of claim 15 wherein the meta-data further identifies, for each of the at least one of the one or more HBs, a respective number of HBs representing the respective HB and the respective one or more other HBs.17.The method of claim 1 wherein the computer program and the meta-data each belong to a same extended executable.18.The method of claim 17 wherein the meta-data is embedded in the computer program.19.The method of claim 1 wherein the prefetching element includes at least one of a load-store unit and an instruction-fetch unit.20.The method of claim 19 wherein the prefetching element further includes a prefetch buffer.21.The method of claim 20 further comprising, at the electronic device:removing, by the prefetch buffer, at least one of the one or more cache-line addresses pushed to the prefetching element, the at least one cache-line address being a duplicate of one other cache-line address of the one or more cache-line addresses pushed to the prefetching element.22.The method of claim 1 wherein the same pre-determined threshold is adjustable.23.The method of claim 1 wherein the same pre-determined threshold is fixed.24.The method of claim 1 wherein the same pre-determined threshold is about 80%.25.The method of claim 1 wherein the one or more iterations includes at least 50 iterations.26.An electronic device comprising a processing unit coupled to one or more tangible, processor-readable memory caches, the processing unit configured to perform the method according to any one of claims 1 to 25.27.A method comprising, at an electronic device including a processor coupled to tangible, processor-readable memory:receiving a computer program including a plurality of instructions defining a plurality of basic blocks (BBs) ;profiling the computer program to identify a plurality of transitions each between a respective pair of BBs, each transition representing a branch in the computer program;demarcating a plurality of hyperblocks (HBs) for the computer program, each HB encompassing, from among the plurality of BBs, a respective series of BBs having therebetween threshold transitions, each threshold transition being one transition of the plurality of transitions having associated thereto a respective likelihood meeting a same pre-determined threshold; andproviding meta-data for the computer program, the meta-data identifying the plurality of HBs and, for each HB, a respective one or more cache-line addresses corresponding to the respective series of BBs.28.The method of claim 27 wherein:the method further comprises, at the electronic device:determining, for each of one or more HBs of the plurality of HBs, a respective most-likely successor (MLS) in accordance with the respective likelihood of the plurality of transitions; andthe meta-data further identifies, for each of the one or more HBs of the plurality of HBs, the respective MLS.29.The method of claim 28 wherein:the method further comprises, at the electronic device:detecting, between each pair of HBs of at least one pair of HBs from among the one or more HBs, a respective transition loop representing, in the computer program, at least one repetition of a respective one transition of the plurality of transitions, the respective one transition, for each pair of HBs of the at least one pair of HBs, being between the respective series of BBs of each HB of the respective pair of HBs; anddetermining, for each of the one or more HBs of the plurality of HBs, the respective MLS includes:determining, for each of a respective one HB of each pair of HBs of the at least one pair of HBs, the respective MLS in accordance with the respective transition loop, the respective one HB of each pair of HBs succeeding, in the computer program, the other HB of the respective pair of HBs.30.The method of claim 28 wherein:the method further comprises, at the electronic device,detecting, between each pair of HBs of at least one pair of HBs from among the one or more HBs, a respective one or more large call-stacks each including a plurality of HBs from among the plurality of HBs; anddetermining, for each of the one or more HBs of the plurality of HBs, the respective MLS includes:determining, for each of a respective one HB of each pair of HBs of the at least one pair of HBs, the respective MLS in accordance with the respective one or more large call-stacks, the respective one HB of each pair of HBs preceding, in the computer program, the other HB of the respective pair of HBs.31.The method of claim 27 wherein the meta-data further identifies, for each HB of the plurality of HBs, a respective program counter and a respective HB type.32.The method of claim 31 wherein the respective HB type for at least one HB of the plurality of HBs indicates a call HB type.33.The method of claim 32 wherein the meta-data further identifies, for each HB of the plurality of HBs, a respective most-likely next HB.34.The method of claim 32 wherein the meta-data further identifies, for each HB of the at least one HB of the plurality of HBs, a respective return address.35.The method of claim 31 wherein the respective HB type for at least one HB of the plurality of HBs indicates a return HB type.36.The method of claim 27 wherein the meta-data further identifies, for each of at least one HB of the plurality of HBs, a respective one or more additional cache-line addresses corresponding to the series of BBs for a respective one or more other HBs being respective targets of the respective HB.37.The method of claim 36 wherein the meta-data further identifies, for each of the at least one HB of the plurality of HBs, a respective number of HBs representing the respective HB and the respective one or more other HBs.38.The method of claim 27 wherein the same pre-determined threshold is adjustable.39.The method of claim 27 wherein the same pre-determined threshold is fixed.40.The method of claim 27 wherein the same pre-determined threshold is about 80%.41.An electronic device comprising a processor coupled to tangible, processor-readable memory, the processor configured to perform the method according to any one of claims 27 to 40.
Citation Information
Patent Citations
BTB fusion method under prefetching mechanism
CN109634666A
Branch target buffer arrangement for instruction prefetching
CN111971654A
Branch prefetch mechanism for mitigating front-end branch reboot
CN114327633A
Processor architecture for multipass processing of instructions downstream of a stalled instruction
US20080028183A1
Generating object code that uses calculated contents for a variable determined from a predicate
US20110055808A1