Improvements in nested conditional checking

Abstract

The present disclosure relates to improved instrumentation for nested conditional checks. Aspects of the invention include performing a first phase, the first phase including instrumenting program code in response to identifying an internal conditional check in the program code, and running the instrumented program with a representative workload. The instrumenting includes copying the internal conditional check and placing the copy of the internal conditional check before a corresponding original nested conditional check in the program code to create an instrumented program. The instrumented program includes a plurality of basic blocks and newly added basic blocks, the basic blocks including original basic blocks, the newly added basic blocks including the copy of the internal conditional check.

Description

Technical Field

[0001] This invention relates generally to optimizing computer code, and more specifically to improving profile-guided optimization (PGO) instrumentation for nested condition checks. Background Technology

[0002] Compilers can perform performance optimizations by using known heuristics to guess code execution. For example, a compiler can predict the static frequency of branches based on where they are located, and / or select inline functions based on function size. For good performance to be achieved, it is important for programmers to have inherent knowledge of compilers and system design, allowing them to provide hints or comments to the compiler. Unfortunately, this is not always possible, and another performance optimization technique that can be used is profile-guided optimization (PGO).

[0003] PGO is a method used by compilers to generate optimal code by using application runtime data. Because this data comes directly from the application, the compiler can make more accurate guesses about code execution. PGO has two phases. During the first phase, the program being compiled is instrumented. As the program runs, using input data representing a typical workload, the injected instrumentation collects features of the program that are useful to the optimizer. During the second phase, the data collected in the first phase is used to re-optimize the program. The collected information is used to make better heuristically guided optimization decisions.

[0004] One technique used by PGO is to inject instrumentation that collects counters representing the execution frequency of basic blocks in a function. Basic blocks with higher counters execute more frequently than those with lower counters. Optimization can use this information to enhance the cost model used to determine whether code changes are considered profitable. Summary of the Invention

[0005] Various embodiments of the invention relate to improved instrumentation for profile-guided nested condition checks. A non-limiting example computer implementation of a method includes performing a first phase comprising: injecting an instrumentation into program code in response to identifying internal condition checks; and running the instrumentation program with a representative workload. The injection includes copying the internal condition checks and placing a copy of the internal condition checks before corresponding original nested condition checks in the program code to create the instrumentation program. The instrumentation program includes a plurality of basic blocks and newly added basic blocks, the basic blocks including the original basic blocks, the newly added basic blocks including copies of the internal condition checks. The method further includes performing a second phase comprising collecting execution frequency values ​​from counters associated with the basic blocks to form metadata for making optimization decisions about the program code.

[0006] Other embodiments of the present invention implement the features of the above-described method in computer systems and computer program products.

[0007] Additional technical features and advantages are achieved through the technology of this invention. Embodiments and aspects of the invention are described in detail herein and are considered part of the claimed subject matter. For a better understanding, refer to the detailed description and accompanying drawings. Attached Figure Description

[0008] The details of the exclusive rights described herein are specifically pointed out and explicitly claimed in the claims at the end of the specification. The foregoing and other features and advantages of embodiments of the invention will become clear from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0009] Figure 1 This describes an instance of a condition check nested within another condition check;

[0010] Figure 2 Examples of current instrumentation techniques are described;

[0011] Figure 3 Examples of insertion techniques according to one or more embodiments of the present invention are described;

[0012] Figure 4 Examples of program code with interchangeable second-level nested condition checks according to one or more embodiments of the present invention are described;

[0013] Figure 5 A block diagram depicting components of a system for configuration file boot optimization (PGO) instrumentation for nested condition checks according to one or more embodiments of the present invention is provided.

[0014] Figure 6 This is an example of source code containing nested condition checks according to one or more embodiments of the present invention;

[0015] Figure 7 (including) Figure 7A and Figure 7B (This describes one or more embodiments of the invention.) Figure 6 The control flow diagram of the source code;

[0016] Figure 8 The process flow of a PGO instrumentation method for nested condition checking according to one or more embodiments of the present invention is shown;

[0017] Figure 9 The invention describes one or more embodiments thereof. Figure 6 The dominator tree of the source code;

[0018] Figure 10 The invention illustrates one or more embodiments of the invention. Figure 6 The post-dominator tree of the source code;

[0019] Figure 11 The invention illustrates one or more embodiments of the invention. Figure 6 The source code for the transformation;

[0020] Figure 12 Describes the process following PGO instrumentation generation and propagation. Figure 6 Source code;

[0021] Figure 13 A processing flow of a method for PGO instrumentation for nested condition checking according to one or more embodiments of the present invention is described; and

[0022] Figure 14 A block diagram of an example computer system used in conjunction with one or more embodiments of the present invention is depicted.

[0023] The figures depicted herein are illustrative. Many variations of the figures or the operations described therein may exist without departing from the spirit of the invention. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Furthermore, the term "coupled" and its variations describe a communication path between two elements and do not imply a direct connection between the elements, with no intervening element / connection between them. All such variations are considered part of the specification. Detailed Implementation

[0024] One or more embodiments of the present invention provide novel instrumentation techniques in the context of Profiling-Guided Optimization (PGO) that can be used to obtain more precise profiling information about functions in a computer program. One or more embodiments of the present invention utilize the obtained profiling information to provide improved PGO instrumentation for nested condition checks in a computer program. Additional information obtained from the improved PGO instrumentation is used to perform heuristically guided optimization decisions, which may include reordering nested condition checks in a runtime-saveable manner.

[0025] Turn now Figure 1 This typically shows an example of source code 100 containing a condition check nested within another condition check. Figure 1The example shown executes a function called "foo" and contains two condition checks nested within a first condition check 102: the first condition check 102 "if(A())" and the second condition check 104 "if(B())". The second condition check 104 can be called the "inner condition check" because it is nested within the first condition check 102. Figure 1 The source code 100 shown is a simplified example herein used to illustrate one or more embodiments of an improved PGO instrumentation for nested condition checks. Those skilled in the art will understand that one or more embodiments of the invention described herein can be extended to more complex control flows involving numerous nested condition checks.

[0026] Turn now Figure 2 This typically shows an example of instrumented source code 200. Figure 2 In the example shown, modern insertion technology is used for insertion. Figure 1 Source code 100, resulting in instrumented source code 200. For example... Figure 2 As shown, Figure 1 Each basic block in source code 100 has an associated PGO counter, and each counter increments whenever its associated basic block is executed at runtime. The first counter 206 "pgo_counter1" represents the number of times the function "foo" is input, the second counter 202 "pgo_counter2" represents the number of times function A evaluates to true, and the third counter 204 "pgo_counter3" represents the number of times both function A and function B evaluate to true. It is known that the third counter 204 "pgo_counter3" will contain values ​​equal to or less than the value of the second counter 202 "pgo_counter2" because the basic block associated with the third counter 204 executes only when both conditions are true, while the basic block associated with the second counter 202 executes only when one condition (A()) evaluates to true.

[0027] By modern PGO technology (such as Figure 2 The information provided by the technique shown is insufficient to infer how many times function B() evaluates to true when A() evaluates to false. If the compiler knew how many times function B() evaluates to true, its optimizer could reorder condition checks from least frequent true to most frequent true to reduce function execution time. One or more embodiments of the present invention overcome this deficiency in contemporary methods by providing an improved PGO instrumentation technique that copies or clones the inner condition check and places it before the original nested condition check, as follows. Figure 3 As shown in the image.

[0028] Now go to Figure 3According to one or more embodiments of the present invention, examples of instrumented source code 300 are generally shown. For example... Figure 3 As shown, a copy of the appended source code 304 and the internal condition check (second condition check 104 "if(B())") is inserted into Figure 2 The instrumentation source code is in 200. Additional source code 304 includes a second conditional check 104 "if(B())" and a fourth counter 302 "pgo_counter4". The value of the fourth counter 302 can be interpreted as the number of times function B() evaluates to true, independent of the evaluation of function A(). At first glance, adding another conditional check and an additional counter might seem unintuitive, as copying the internal conditional check increases execution time. However, this is not the case, because the PGO instrumentation is injected by the compiler in the first stage (the instrumentation stage) and therefore will not affect the execution time of the final optimized program output by the compiler in the second stage of generating the optimized executable code.

[0029] Additional profile information or metadata collected by one or more embodiments of the present invention supports additional optimization decisions during the recompile phase as described herein, ultimately resulting in better runtime performance for the optimizer. Figure 4 Examples of additional optimizations based on additional information provided by one or more embodiments of the present invention are shown.

[0030] Now go to Figure 4 According to one or more embodiments of the present invention, examples of original program code 402 and optimized program code 404 are generally shown. Figure 4 The examples in the text show examples based on, for example, from Figure 3 The data collected by the counter in the instrumentation source code 300 is used for two-level nested condition checks that are interchangeable according to one or more embodiments of the present invention.

[0031] exist Figure 4 In the example shown, it is assumed that function B() evaluates to false more frequently than function A() evaluates to false, and that neither function has side effects (e.g., they do not modify global variables, etc.). Figure 4As shown, swapping the two condition checks results in a reduction in the number of times function A() is called. For example, based on instrumentation, it can be determined that function "foo" is executed ten times, function A() evaluates to false zero in those ten executions, and function B() evaluates to false seven in those ten executions. The cost of executing the original program code 402 is calculated as ten times the cost of executing function (A) + ten times the cost of executing function (B) (10A_cost + 10B_cost). The cost of executing the optimized program code 404 is calculated as ten times the cost of executing function (B) + three times the cost of executing function (A) (10B_cost + 3A_cost). The above savings assume that the complexities of functions A() and B() are approximately equal. The complexity of the functions can be estimated using any technique known in the art.

[0032] The examples described herein relate to the results of functionality. Those skilled in the art will recognize that one or more embodiments described herein can also be applied to conditions that can be evaluated (e.g., A+B).

[0033] Now go to Figure 5 According to one or more embodiments of the present invention, a block diagram of the components of a system 500 for PGO instrumentation for nested condition checks is generally shown. (See reference...) Figure 5 The described processing, in whole or in part, can be handled by Figure 14 The system 1400 can execute all or a subset of its components. Figure 5 The system 500 shown includes a compiler 502, an execution unit 504, and a data storage 506.

[0034] Compiler 502 may be implemented by any compiler known in the art that can enhance or modify the improved PGO instrumentation described herein to include the improved PGO instrumentation described herein. According to one or more embodiments of the invention, the compiler is... Figure 14 The system 1400 shown is an implementation of all or part of it. Examples of compilers 502 that can be used include, but are not limited to: IBM XL compiler, LLVM, and GCC. Figure 5 As shown, during the first pass or instrumentation stage, compiler 502 receives source code 508 and adds counters or other probes to source code 508 to generate instrumented source code 510. Figure 1 Source code 100 is an example of source code 508, and instrumented source code 200 is an example of instrumented source code 510. During the first pass, compiler 502 uses probe 514 to generate executable code that will be executed by execution unit 504.

[0035] Execution unit 504 can be implemented by any processor known in the art for executing computer code. Execution unit 504 uses input data from data storage device 506 to execute executable code using probe 514 to generate instrumented data 516 (also referred to herein as "metadata"). According to one or more embodiments of the invention, the input data from data storage 506 represents a typical workload executed by source code. Execution unit 504 outputs instrumented data 516 (e.g., counter values, etc.) in addition to other data outputs (not shown) typically generated by source code.

[0036] During the second pass or optimization phase, compiler 502 generates optimized executable code 512 based on source code 508 and instrumentation data 516. Optimized program code 404 is an example of optimized executable code 512.

[0037] Data storage 506 may be implemented using any one or more storage mechanisms known in the art, such as, but not limited to, databases, storage devices, and / or file systems. Data storage 506 may store data used as input to the code when it is executed. Furthermore, data storage 506 may store all or a subset of data output by the code during execution, instrumented data 516, instrumented source code 510, source code 508, optimized executable code 512, and executable code with probe 514.

[0038] It should be understood that, Figure 5 The block diagram is not intended to indicate that the system 500 includes Figure 5 All the components shown. Conversely, system 500 may include... Figure 5 Any suitable fewer or additional components not shown in the diagram (e.g., additional compiler / execution units, inputs, outputs, etc.). Furthermore, Figure 5 One or more components shown may be combined together or separated into two or more components. Components may be directly connected or connected via one or more networks. Furthermore, the embodiments described herein with respect to system 500 may be implemented with any suitable logic, wherein the logic mentioned herein may include any suitable hardware (e.g., processor, embedded controller, or application-specific integrated circuit, etc.), software (e.g., application, etc.), firmware, or any suitable combination of hardware, software, and firmware.

[0039] Now go to Figure 6 According to one or more embodiments of the present invention, an example of source code 600 including nested condition checks is generally shown. Figure 6 The source code 600 shown herein is used to illustrate one or more embodiments of an improved PGO instrumentation for nested condition checks. Source code 600 is... Figure 5 Example of source code 508.

[0040] Now turn to Figure 7, which includes Figure 7A and 7B According to one or more embodiments of the present invention, it is generally shown Figure 6 The source code 600 contains a control flow diagram 700. Control flow diagram 700 is a representation, using graphical annotations, of all paths traversable through basic blocks in the program during program execution. Each block in Figure 7 is a basic block (e.g., "if.then.func1" represents the basic block when "func1()" is evaluated as true). The control flow diagram 700 shown in Figure 7 can be compiled by a compiler (such as...). Figure 5 The compiler 502) uses any method known in the art from Figure 6 The source code was generated in 600.

[0041] Figure 7A The control flow diagram 700 includes a first block 702, which enters the function "foo", initializes the value of variable "x" to zero, evaluates the result from "func1", branches to block 716 if "func1" evaluates false, and branches to block 704 if "func1" evaluates true. Block 704 evaluates the result returned by "func2", branches to block 706 if "func2" evaluates true, and branches to block 714 if "func2" evaluates false. Block 714 marks the end of the if / then / else processing or nested conditional checks, depending on the Boolean value returned by "func2". Block 706 evaluates the result from "func3", branches to block 708 if "func3" evaluates true, and branches to block 710 if "func3" evaluates false. At block 708, the value of variable x is set to 1 and the flow branches to block 712. In block 710, the value of variable x is set to 2, and the flow branches to block 712. Block 712 marks the end of the if / then / else processing or nested conditional checks, depending on the boolean value returned by "func3".

[0042] like Figure 7BAs shown, block 716 ends the portion of the nested condition check that depends on the value returned by "func1", evaluates the result from "func4", branches to block 724 if "func4" evaluates false, and branches to block 718 if "func4" evaluates true. Block 718 evaluates the result from "func5", branches to block 720 if "func5" evaluates true, and branches to block 722 if "func5" evaluates false. At block 720, the value of variable x is set to 3, and the flow continues at block 722. Block 722 indicates the end of the if / then processing, or part of the nested condition check depending on the boolean value returned by "func5". The flow continues at block 724, where the portion of the nested condition check that depends on the value returned by "func4" ends, and the value of variable x is returned.

[0043] Turn now Figure 8 According to one or more embodiments of the present invention, a process flow of a method 800 for PGO instrumentation for nested condition checks is generally shown. Figure 8 The method 800 shown can be derived from, for example... Figure 5 The compiler executes in block 502. In block 802, the dominator tree and post-dominator tree are built for the source code being optimized. Figure 9 The description corresponds to one or more embodiments of the present invention. Figure 6 An instance of the dominator tree 900 in the source code (and therefore the control flow diagram of Figure 7). As is known in the art, a dominator tree is a tree in which the children of each node are those nodes that it immediately dominates. Figure 10 The illustration shows a corresponding embodiment of one or more of the present invention. Figure 6 An instance of the post-dominant tree 1000 of the source code (and thus the control flow graph of Figure 7). As is known in the art, the initial node or block 724 in the post-dominant tree is the exit node of the control flow graph, and the parent node of each node is its immediate post-dominant. Figure 9 The shown master tree 900 and Figure 10 The post-dominant tree 1000 shown can be constructed using any method known in the art.

[0044] exist Figure 8 Block 804 uses a dominator tree to collect candidate condition branches. According to one or more embodiments of the invention, the dominator tree is traversed in a breadth-first manner to populate the candidate set with nodes or blocks having more than one child. Figure 9In the dominator tree 900 shown, the basic blocks that satisfy this requirement are blocks 702, 704, 716, 706, and 718. The candidate conditional branch set (or "candidate set") is then pruned by removing basic blocks terminated by instructions that depend on instructions that may have side effects. Examples of instructions that may have potential side effects include, but are not limited to, instructions that modify global or static variables, write to a database, a file, or the console. Speculative execution is unsafe if an instruction has potential side effects.

[0045] References in this article Figure 6 In the instance described in source code 600, it is assumed that "func1", "funct2", "func3", and "func4" have no side effects, while "func5" may have side effects. In response, block 718 "if.then.func4" is removed from the candidate set. This results in the candidate set being {block 702 "entry", block 704 "if.then.func1", block 716 "if.end.func1", and block 706 "if.then.func2"}.

[0046] exist Figure 8 At block 806, the outermost possible position of the cloning or replication conditional branch is determined. According to one or more embodiments of the invention, this is performed by traversing the predecessor nodes (in the same set) of each node in the candidate set in a top-down order. If an ancestor node is equivalent to the control flow of the current node, another ancestor node is considered. Basic blocks A and B are control flow equivalents if and only if A dominates B and B dominates A. Otherwise, the termination instruction in the current node is analyzed. If a termination instruction prior to the termination instruction of an ancestor node is safe for cloning, an entry specifying this is added to the clone position map. For example, an entry such as {currentNode->ancestorNode} is added to the clone position map.

[0047] Both the dominator tree and the post-dominant tree can be used to determine whether two basic blocks are control flow equivalent. (See reference...) Figure 6 See the example source code. Figure 9 The Dominator Tree 900 and Figure 10 The post-dominant tree 1000, let the candidate set = {block 702 "entry", block 704 "if.then.func1", block 716 "if.end.func1" and block 706 "if.then.func2"} is from Figure 8 The set of candidate basic blocks derived from block 804. The processing applied to this run example, executed at block 806, produces:

[0048] The "entry" 702 is a candidate node selected from this set. Because the "entry" 702 has no ancestor node in the candidate set, it is discarded.

[0049] Block 704 "if.then.func1" is the selected next candidate node, whose preceding node is block 702 "entry". Block 702 "entry" is not equivalent to the control flow of block 704 "if.then.func1". Furthermore, the termination instruction in block 704 "if.then.func1" is safe for cloning before the termination instruction in block 702 "entry", and thus the entry {block 704 "if.then.func1" -> block 702 "entry"} is created in the clone position mapping.

[0050] Make block 716 "if.end.func1" the selected next candidate node, whose preceding node is block 702 "entry". Block 702 "entry" is the control flow equivalent to block 716 "if.end.func1", so it is skipped.

[0051] Make block 706 "if.then.func2" the selected next candidate node. It has two ancestor nodes, block 702 "entry" and block 704 "if.then.func1". Block 702 "entry" is not equivalent to the control flow of block 704 "if.then.func1". Furthermore, the termination instruction in block 706 "if.then.func2" is safely cloned before the termination instruction in block 702 "entry". Therefore, add the entry {block 706 "if.then.func2" -> block 702 "entry"} in the clone position mapping.

[0052] In this example, the clone location map contains {{block 704 "if.then.func1" -> block 702 "entry"}, {block 706 "if.then.func2" -> block 702 "entry"}}

[0053] exist Figure 8 At block 808, the conditional branch is cloned to the target location identified in the clone location map. For each entry in the clone location map, the following operations are performed:

[0054] The termination instruction, along with any instructions it depends on, is cloned into the basic block identified by the mapping "key," and the cloned instruction is injected before the terminator of the basic block identified by the mapping value.

[0055] The basic block obtained by splitting the original basic block exactly before the original terminator. Let's assume the original basic block is called BB1 and the new basic block is called BB2.

[0056] Insert a new basic block named BB3, making its only successor BB2, and modify the conditional branch that terminates BB1, making its successors BB3 (true branch) and BB2 (false branch).

[0057] According to one or more embodiments of the invention, during the cloning of block 808, if the termination instruction depends on the invocation instruction, the callee is cloned, and the invocation instruction of the clone is modified to invoke the new callee. This avoids erroneously incrementing the PGO counter of the original callee. Figure 11 An instance of the transformed source code 1100 for the running instance described herein is depicted, wherein the termination instruction in block 704 “if.then.func1” is “br i1%result.func2,label%if.then.func2,label%if.end.func2” and the termination instruction in block 706 “if.then.func2” is “br i1%result.func3,label%if.then.func3,label%if.end.func3”. The terminator of block 702 “entry” is “br i1%result.func1,label%if.then.func1,%if.end.func1”.

[0058] Turn now Figure 11 According to one or more embodiments of the present invention, generally shown are those corresponding to Figure 6 The source code 600 is transformed into source code 1100. For example... Figure 11 As shown, in blocks 704 and 706, the transformed source code 1100 includes additions to... Figure 6 The source code 600 contains two additional instructions 1102, which represent the termination instruction and any instructions it depends on. The repeated additional instructions 1102 are inserted before the terminator in module 720.

[0059] According to one or more embodiments of the present invention, a new transformed source code 1100 is generated prior to the PGO instrumentation generation pass. Existing mechanisms for inserting PGO instrumentation counters can be based on the transformed source code generated by one or more embodiments of the present invention to insert new counters for newly created basic blocks without modifying existing PGO mechanisms.

[0060] Source code can be broken down into multiple blocks or basic blocks. As used herein, the term "original basic block" refers to instructions in the original source code, such as... Figure 6 The instructions in source code 600. According to one or more embodiments of the present invention, Figure 6The original basic blocks of source code 600 are shown in the control flow diagram 700 of Figure 7, where each block in Figure 7 represents an original basic block. As used herein, the term "newly added basic block" refers to instructions added through the instrumentation stage. Figure 11 Each of the additional instructions 1102 shown can be referred to as a newly added basic block.

[0061] Turn now Figure 12 According to one or more embodiments of the present invention, the process generally shown after the PGO instrumentation generation transfer is illustrated. Figure 11 The converted source code 1100. Figure 12 The instrumented code 1200 shown includes an instrumentation inserted by PGO instrumentation (in this example counter). The instrumented source code 1200 is... Figure 5 Example of instrumented source code 510.

[0062] After running a tooltip with a representative workload, counters representing the execution frequency of newly added and original basic blocks are collected. In the second phase, the transformation algorithm is similar to the reference... Figure 8 The aforementioned processing. (See reference.) Figure 8 The processing described in blocks 802, 804, and 806 is the same; however, block 808 differs slightly in the second phase. According to one or more embodiments of the invention, when a control flow change is performed and a new basic block is created, an entry is added to the associated block mapping from the new basic block to its associated block. For example, given the entry {block 704 "if.then.func1" -> block 702 "entry"} in the clone location mapping, the entry {new block -> block 704 "if.then.func1"} is also added to the associated block mapping before the creation of the new basic block, which is called the new block before the terminator of block 702 "entry".

[0063] At this point, the control flow diagram is identical to that from the first stage. The compiler can then read the profile data collected for the new basic blocks and store that information, along with the new metadata, in their associated original basic blocks. For example, from the profile data collected for the new blocks, metadata blocks 704 "if.then.func1" and 702 "Entry" are created for the termination instructions of the basic blocks, where the metadata of block 704 "if.then.func1" references the metadata of block 702 "Entry" and the counter collected for the new blocks. This metadata can indicate the number of times the termination condition of block 704 "if.then.func1" evaluates to true, regardless of the termination conditions following block 702 "Entry".

[0064] By referring to the associated block diagram, by undoing in Figure 8The second phase is completed by adding control flow changes to block 808 (the second-phase modification). This results in no changes except for new metadata from the transformed code in the second phase. The new metadata can be used to make better heuristically guided optimization decisions, for example, by making a better estimate of the program's control flow. The compiler uses the metadata to generate the executable. Examples of heuristically guided optimization decisions include (but are not limited to) block ordering, changing the order of nested conditional code instructions, function inlining (e.g., to reduce function call overhead), and generalization.

[0065] Now go to Figure 13 According to one or more embodiments of the present invention, a processing flow of a method 1300 for PGO instrumentation for nested condition checks is generally shown. Figure 13 The method 1300 shown can be, for example, by Figure 5 The compiler 502 executes.

[0066] The first phase of detection is performed at block 1302. The first phase includes injecting an instrumentation program in response to identifying one or more internal condition checks. Injection may include copying the internal condition checks and placing a copy of the internal condition checks before the corresponding original nested condition checks in the program code as described herein to create an instrumentation program. The instrumentation program comprises multiple basic blocks, including the original basic blocks and newly added basic blocks that include copies of the internal condition checks. Finally, the instrumentation program is executed using a representative workload.

[0067] At block 1304, the second phase (optimization) is performed. The second phase involves collecting execution frequency values ​​from the first-phase counters associated with the basic block to form metadata that the compiler uses to make heuristically guided optimization decisions. As used herein, the term "metadata" refers to additional basic block frequency information parsed earlier in the program for the associated basic block.

[0068] Figure 8 and Figure 13 The process flowchart is not intended to indicate that the operations of methods 800 and 1300 should be performed in any particular order, or that all operations of each of methods 800 and 1300 should be included in every case. Furthermore, each of methods 800 and 1300 may include any suitable number of additional operations.

[0069] Turn now Figure 14A computer system 1400 is generally illustrated according to an embodiment. The computer system 1400 may be an electronic computer architecture comprising and / or employing any number and combination of computing devices and networks utilizing different communication technologies, as described herein. The computer system 1400 may be easily expandable, scalable, and modular, with the ability to be changed to different services or reconfigured to some features independently of others. The computer system 1400 may be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, the computer system 1400 may be a cloud computing node. The computer system 1400 may be described in the general context of computer system executable instructions (such as program modules) executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. The computer system 1400 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules may reside in local and remote computer system storage media, including memory storage devices.

[0070] like Figure 14 As shown, computer system 1400 has one or more central processing units (CPUs) 1401a, 1401b, 1401c, etc. (collectively or generally referred to as processors 1401). Processor 1401 may be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. Processor 1401 (also referred to as processing circuitry) is coupled to system memory 1403 and various other components via system bus 1402. System memory 1403 may include read-only memory (ROM) 1404 and random access memory (RAM) 1405. ROM 1404 is coupled to system bus 1402 and may include a basic input / output system (BIOS) that controls certain basic functions of computer system 1400. RAM is a read-write memory coupled to system bus 1402 for use by processor 1401. System memory 1403 provides temporary memory space for the operation of instructions during operation. System memory 1403 may include random access memory (RAM), read-only memory, flash memory, or any other suitable memory system.

[0071] Computer system 1400 includes an input / output (I / O) adapter 1406 and a communication adapter 1407 coupled to a system bus 1402. I / O adapter 1406 may be a Small Computer System Interface (SCSI) adapter that communicates with a hard disk 1408 and / or any other similar component. I / O adapter 1406 and hard disk 1408 are collectively referred to herein as mass storage 1410.

[0072] Software 1411 for execution on computer system 1400 may be stored in mass storage device 1410. Mass storage 1410 is an example of a tangible storage medium readable by processor 1401, wherein software 1411 is stored as instructions for execution by processor 1401 to operate computer system 1400, such as those described below with respect to the various figures. Examples of computer program products and the execution of these instructions are discussed in more detail herein. Communication adapter 1407 interconnects system bus 1402 with network 1412, which may be an external network enabling computer system 1400 to communicate with other such systems. In one embodiment, a portion of system memory 1403 and mass storage 1410 jointly store an operating system, which may be any suitable operating system, such as those from International Business Machines Corporation. or Operating system, to coordinate Figure 14 The functions of each component are shown below.

[0073] Additional input / output devices are shown connected to system bus 1402 via display adapter 1415 and interface adapter 1416. In one embodiment, adapters 1406, 1407, 1415, and 1416 may be connected to one or more I / O buses connected to system bus 1402 via an intermediate bus bridge (not shown). Display 1419 (e.g., screen or display monitor) is connected to system bus 1402 via display adapter 1415, which may include a graphics controller and a video controller for improving performance in graphics-intensive applications. Keyboard 1421, mouse 1422, speaker 1423, etc., may be interconnected to system bus 1402 via interface adapter 1416, which may include, for example, a super I / O chip integrating multiple device adapters into a single integrated circuit. Suitable I / O buses for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols such as Peripheral Component Interconnect (PCI). Therefore, as Figure 14 The computer system 1400 configured therein includes processing power in the form of a processor 1401, storage capacity including system memory 1403 and mass storage 1410, input devices such as a keyboard 1421 and a mouse 1422, and output capacity including a speaker 1423 and a display 1419.

[0074] In some embodiments, the communication adapter 1407 may use any suitable interface or protocol (such as an Internet Small Computer System Interface) to send data. The network 1412 may be a cellular network, radio network, wide area network (WAN), local area network (LAN), or the Internet. External computing devices may be connected to the computer system 1400 via the network 1412. In some examples, the external computing device may be an external web server or a cloud computing node.

[0075] It should be understood that Figure 14 The block diagram is not intended to indicate which computer system 1400 will include Figure 14 All components shown. Conversely, computer system 1400 may include... Figure 14 Any suitable fewer or additional components not shown herein (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Furthermore, the embodiments described herein with respect to computer system 1400 can be implemented with any suitable logic, wherein the logic as mentioned herein may include any suitable hardware (e.g., processor, embedded controller, or application-specific integrated circuit, etc.), software (e.g., applications, etc.), firmware, or any suitable combination of hardware, software, and firmware.

[0076] Various embodiments of the invention are described herein with reference to the accompanying drawings. Alternative embodiments of the invention may be devised without departing from its scope. In the following description and drawings, various connections and positional relationships (e.g., above, below, adjacent, etc.) are illustrated between elements. Unless otherwise specified, these connections and / or positional relationships may be direct or indirect, and the invention is limited in this respect by not illustrating the figures. Therefore, the connection of entities may refer to direct or indirect connections, and the positional relationship between entities may be direct or indirect positional relationships. Furthermore, the various tasks and process steps described herein may be incorporated into a more comprehensive procedure or process with additional steps or functions not described in detail herein.

[0077] One or more methods described herein can be implemented using any of the following techniques or combinations thereof, each of which is well known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having appropriately combined logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0078] For the sake of brevity, conventional techniques relating to the manufacture and use of the present invention may or may not be described in detail herein. Specifically, various aspects of the computing systems and specific computer programs used to implement the different technical features described herein are well known. Consequently, for the sake of brevity, many conventional implementation details are only briefly mentioned or omitted entirely herein, without providing well-known system and / or process details.

[0079] In some embodiments, various functions or actions may occur at a given location and / or in conjunction with the operation of one or more devices or systems. In some embodiments, a portion of a given function or action may be performed at a first device or location, and the remainder of the function or action may be performed at one or more additional devices or locations.

[0080] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well. It should also be understood that when the terms “comprises” and / or “comprising” are used in this specification, they specify the presence of the stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or combinations thereof.

[0081] All means or steps in the following claims, plus corresponding structures, materials, actions, and equivalents of the functional elements, are intended to include any structure, material, or action for performing the function in conjunction with other claimed elements as specifically claimed. This disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the forms disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of this disclosure. These embodiments were chosen and described in order to best explain the principles and practical application of this disclosure, and to enable others skilled in the art to understand this disclosure with respect to different embodiments having different modifications suitable for the particular intended use.

[0082] The diagrams depicted herein are illustrative. Many variations may be made to the diagrams or steps (or operations) described herein without departing from the spirit of this disclosure. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Furthermore, the term "coupled" describes a signal path between two elements and does not imply a direct connection between elements without intermediate elements / connections. All such variations are considered part of this disclosure.

[0083] The following definitions and abbreviations will be used to interpret the claims and description. As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” “contains,” or “containing,” or any other variations thereof, are intended to cover non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus.

[0084] Furthermore, the term "exemplary" is used herein to mean "used as an example, illustration, or illustration." Any implementation or design described herein as "exemplary" is not necessarily to be construed as superior to or better than other implementations or designs. The terms "at least one" and "one or more" should be understood to include any integer greater than or equal to one, i.e., one, two, three, four, etc. The term "multiple" should be understood to include any integer greater than or equal to two, i.e., two, three, four, five, etc. The term "connection" can include both indirect "connection" and direct "connection."

[0085] The terms “about,” “substantially,” “roughly,” and their variations are intended to include the degree of error associated with a measurement based on a specific quantity of equipment available at the time of application submission. For example, “about” could include a range of ±8%, 5%, or 2% of a given value.

[0086] This invention can be a system, method, and / or computer program product with any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0087] Computer-readable storage media can be tangible means for retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital universal disk (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or protrusions in slots having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0088] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the suitable computing / processing device.

[0089] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)) or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuitry in order to perform aspects of this invention.

[0090] The present invention will now be described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0091] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, thereby comprising an article of manufacture containing instructions that implement aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0092] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0093] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the diagram. For example, depending on the functions involved, two consecutively shown blocks may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0094] Various embodiments of the invention have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, their practical application, or technical improvements over those found in the market, or to enable those skilled in the art to understand the embodiments described herein.

Claims

1. A computer-implemented method, comprising: The first phase is to be executed, which includes: Instrumentation is injected into the program code in response to an internal condition check identified in the program code, the injection comprising: Copy the internal condition check; and A copy of the inner condition check is placed before the corresponding original nested condition check in the program code to create an instrumentation program. The instrumentation program comprises multiple basic blocks, including original basic blocks and newly added basic blocks that include copies of the inner condition check. Run the instrumentation procedure with a representative workload; and The second phase will be implemented, which includes: Execution frequency values ​​are collected from counters associated with the basic block to form metadata for making optimization decisions about the program code.

2. The method according to claim 1, wherein, The injection further includes adding a counter associated with the newly added basic block to count the number of times the newly added basic block is executed.

3. The method according to claim 1, wherein, The internal condition check is identified at least in part based on the contents of the dominator tree describing the program code.

4. The method according to claim 3, wherein, The internal condition check is selected from a set of candidate condition branches, each of which corresponds to a node in the dominator tree that has more than one offspring and no potential side effects.

5. The method of claim 4, further comprising removing nodes from the set that do not have an ancestor node in the set.

6. The method according to claim 4, wherein, The internal condition check has a different control flow than any of the other nodes in the set.

7. The method according to claim 1, wherein, The injection includes determining the location of a copy of the internal condition check in the program code based at least in part on one or both of traversing the dominator tree describing the program code and traversing the post-dominator tree describing the program code, wherein the placement is at the determined location.

8. The method according to claim 1, wherein, The first and second phases are executed by the compiler.

9. The method of claim 1, further comprising optimizing the program code at least in part based on the metadata.

10. The method according to claim 9, wherein, The optimization includes switching the order of the condition checks in the program code.

11. The method according to claim 1, wherein, Multiple copies of the internal condition check, including a copy of the internal condition check, are placed in the program code.

12. A system for code inspection, comprising: Memory, containing computer-readable instructions; as well as One or more processors for executing the computer-readable instructions, the computer-readable instructions controlling the one or more processors to perform operations, the operations including: The first phase is to be executed, which includes: Instrumentation is injected into the program code in response to an internal condition check identified in the program code, the injection comprising: Copy the internal condition check; and A copy of the inner condition check is placed before the corresponding original nested condition check in the program code to create an instrumentation program. The instrumentation program comprises multiple basic blocks, including original basic blocks and newly added basic blocks that include copies of the inner condition check. Run the instrumentation procedure with a representative workload; and The second phase will be implemented, which includes: Execution frequency values ​​are collected from counters associated with the basic block to form metadata for making optimization decisions about the program code.

13. The system according to claim 12, wherein, The injection further includes adding a counter associated with the newly added basic block to count the number of times the newly added basic block is executed.

14. The system according to claim 12, wherein, The internal condition check is identified at least in part based on the contents of the dominator tree describing the program code.

15. The system according to claim 12, wherein, The injection includes determining the location of a copy of the internal condition check in the program code based at least in part on one or both of traversing the dominator tree describing the program code and traversing the post-dominator tree describing the program code, wherein the placement is at the determined location.

16. The system according to claim 12, wherein, The first and second phases are executed by the compiler.

17. The system according to claim 12, wherein, The operation further includes optimizing the program code based at least in part on the metadata.

18. The system according to claim 12, wherein, Multiple copies of the internal condition check, including a copy of the internal condition check, are placed in the program code.

19. A computer program product comprising a computer-readable storage medium having program instructions contained therein, the program instructions being executable by one or more processors to cause the one or more processors to perform the following operations: The first phase is to be executed, which includes: Instrumentation is injected into the program code in response to an internal condition check identified in the program code, the injection comprising: Copy the internal condition check; and A copy of the inner condition check is placed before the corresponding original nested condition check in the program code to create an instrumentation program. The instrumentation program comprises multiple basic blocks, including original basic blocks and newly added basic blocks that include copies of the inner condition check. Run the instrumentation procedure with a representative workload; and The second phase will be implemented, which includes: Execution frequency values ​​are collected from counters associated with the basic block to form metadata for making optimization decisions about the program code.

20. The computer program product according to claim 19, wherein, Multiple copies of the internal condition check, including a copy of the internal condition check, are placed in the program code.

Images