Arithmetic device, arithmetic method, and program
The computing device optimizes intermediate code by generating and executing intermediate representations based on reference counts, addressing inefficiencies in existing operation conversion methods.
Patent Information
- Application Number
- JP2024528207
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-06-23
- Publication Date
- 2025-08-05
- Estimated Expiration
- 2042-06-23
AI Technical Summary
Existing methods for optimizing intermediate code during operation conversion are inefficient in detecting parts that can be converted into other operations with minimal load.
A computing device and method that generates intermediate representations, determines the feasibility of converting operations with reference counts, and executes the optimized representation, utilizing libraries for source and intermediate code execution.
Enables efficient detection and conversion of intermediate representation parts with reduced computational load, optimizing operation performance.
Smart Images

Figure 0007718591000001 
Figure 0007718591000002 
Figure 0007718591000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to a computing device, a computing method, and program Regarding. [Background technology]
[0002] After the source program is converted into intermediate code, the intermediate code may be optimized. For example, in the technique described in Patent Document 1, analysis information of the source code and the correspondence between the analysis information and code instructions are embedded in the intermediate code, and optimization is performed by combining each module in the intermediate code for each module. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Japanese Patent Application Publication No. 2014-219858 Summary of the Invention [Problem to be solved by the invention]
[0004] When performing operation conversion in an intermediate representation, such as optimizing intermediate code, it is preferable to be able to detect parts of the intermediate representation that can be converted into other operations with as little load as possible.
[0005] An example of the object of the present invention is to provide a calculation device, a calculation method, and program The purpose is to provide [Means for solving the problem]
[0006] According to a first aspect of the present invention, a computing device comprises intermediate representation generation means for generating an intermediate representation corresponding to a portion of a source program that is a program to be executed; conversion feasibility determination means for determining that, among operations indicated in the intermediate representation, an operation in which an object corresponding to the result of the operation is referenced once or less in the source program can be converted into another operation; conversion means for performing processing to convert the intermediate representation based on the determination result of whether the operation can be converted into another operation; and intermediate representation execution means for executing the intermediate representation after processing by the conversion means.
[0007] According to a second aspect of the present invention, a calculation method includes a computer generating an intermediate representation corresponding to a portion of a source program that is a program to be executed, determining that, among operations represented in the intermediate representation, an operation in the source program in which an object corresponding to the result of the operation is referenced once or less can be converted into another operation, performing processing to convert the intermediate representation based on the determination result of whether the operation can be converted into another operation, and executing the intermediate representation after processing by the conversion means.
[0008] According to a third aspect of the present invention, program a program for causing a computer to generate an intermediate representation corresponding to a part of a source program that is a program to be executed; determining that an operation represented by the intermediate representation, which has an object in the source program that corresponds to the result of the operation referenced once or less, can be converted into another operation; performing processing to convert the intermediate representation based on the result of determining whether the operation can be converted into another operation; and executing the intermediate representation processed by the conversion means. In be. [Effects of the Invention]
[0009] According to the present invention, a portion of the intermediate representation that can be converted into other operations can be detected with a relatively small load. [Brief explanation of the drawings]
[0010] [Figure 1]FIG. 1 is a diagram illustrating an example of the configuration of a calculation device according to an embodiment. [Figure 2] FIG. 10 is a diagram illustrating an example of a source program. [Figure 3] FIG. 10 is a diagram illustrating an example of an intermediate representation. [Figure 4] FIG. 2 is a diagram showing an example of an intermediate representation obtained by the optimization process performed by the optimization unit 230. [Figure 5] FIG. 10 is a diagram illustrating an example of a source program that is not suitable for optimization processing. [Figure 6] FIG. 10 is a diagram showing an example of a procedure for a conversion possibility determination unit 231 to detect a convertible part in the intermediate representation. [Figure 7] FIG. 10 is a diagram illustrating a first example of a value of a reference counter. [Figure 8] FIG. 10 is a diagram showing an example of a source program in which functions are directly written as arguments of the functions. [Figure 9] FIG. 10 is a diagram illustrating a second example of the value of the reference counter. [Figure 10] FIG. 10 is a diagram illustrating an example of a source program in which a value is assigned to a global variable. [Figure 11] FIG. 10 is a diagram illustrating an example of a source program with no references after evaluation. [Figure 12] FIG. 10 is a diagram illustrating an example of a source program with references after evaluation. [Figure 13] FIG. 10 is a diagram illustrating another example of the configuration of a calculation device according to an embodiment. [Figure 14] FIG. 10 is a diagram illustrating an example of a processing procedure in a calculation method according to an embodiment. [Figure 15] FIG. 1 is a schematic block diagram illustrating the configuration of a computer according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION
[0011] The following describes embodiments of the present invention, but the following embodiments do not limit the scope of the invention as claimed. Furthermore, not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention. Fig. 1 is a diagram showing an example of the configuration of a computing device according to an embodiment. In the configuration shown in Fig. 1, the computing device 100 includes a communication unit 110, a display unit 120, an operation input unit 130, a storage unit 180, and a control unit 190. The control unit 190 includes a front-end unit 210, a parent library 220, an optimization unit 230, a back-end unit 240, and a child library 250. The optimization unit 230 includes a conversion feasibility determination unit 231 and a conversion unit 232.
[0012] The arithmetic device 100 partially converts a source program, which is a program to be executed such as a user program, into an intermediate representation and executes the converted source program. The arithmetic device 100 may also operate as a just-in-time compiler and partially convert the source program into an intermediate representation and execute the converted source program. Converting a source program into an intermediate representation is also called intermediate representation creation or intermediate representation generation. Generally, a program is not deleted when it is executed. It is also possible for the computing device 100 to leave the parts of the original source program that have been converted into an intermediate representation intact. However, the computing device 100 may also delete the parts of the original source program that have been converted into an intermediate representation. The arithmetic device 100 is configured using a computer such as a personal computer (PC).
[0013] The communication unit 110 communicates with other devices. For example, the communication unit 110 may communicate with another computer, such as a user's terminal device, to receive the source program. However, the method by which the arithmetic device 100 acquires the source program is not limited to a specific method.
[0014] The display unit 120 has a display screen such as a liquid crystal panel or an LED (Light Emitting Diode) panel, and acquires various images. For example, the display unit 120 displays data and the like in accordance with a display command in a source program. The operation input unit 130 includes input devices such as a keyboard and a mouse, and accepts user operations. For example, the operation input unit 130 may accept a user operation to instruct execution of a source program. Alternatively, the display unit 120 may display an editor screen for inputting and editing a source program, and the operation input unit 130 may accept a user operation to program the source program.
[0015] The storage unit 180 stores various types of data. For example, the storage unit 180 may store a source program acquired by the communication unit 110 or the operation input unit 130. The storage unit 180 is configured using a storage device included in the arithmetic device 100.
[0016] The control unit 190 controls each unit of the arithmetic device 100 to perform various processes. In particular, the control unit 190 executes a source program. As described above for the arithmetic device 100, the control unit 190 partially converts the source program into an intermediate representation and executes it. The functions of the control unit 190 are performed by, for example, a CPU (Central Processing Unit) included in the arithmetic device 100 reading out a program from the storage unit 180 and executing it.
[0017] The arithmetic device 100 may include an accelerator such as a GPU (Graphics Processing Unit) in addition to the CPU, and the functions of the control unit 190 may be executed using the accelerator in addition to the CPU. For example, the control unit 190 may convert a portion of the source program that can be executed by a GPU into an intermediate representation for a GPU and execute it on the GPU, and the remaining portion may be executed by the CPU when executing the source program.
[0018] The arithmetic device 100 executes both the source program and the intermediate representation using a library. Executing the intermediate representation here means executing operations and the like indicated in the intermediate representation format. In the configuration of FIG. 1, parent library 220 is an example of a library used to execute a source program, and child library 250 is an example of a library used to execute an intermediate representation.
[0019] The programming languages of the parent library and the source program are not limited to any particular one, and the programming languages of the child library and the intermediate representation are also not limited to any particular one. For example, the programming languages of the parent library and the source program may be languages that provide a relatively wide variety of operations, etc., to make it easier for users to write programs. Furthermore, the programming languages of the child library and the intermediate representation may be languages that provide fewer operations, etc., than the execution of the source program, but have some advantage, such as high speed execution. Furthermore, for example, the programming languages of the child library and the intermediate representation may be domain-specific languages (DSLs) specialized for devices that execute the intermediate representation, such as GPUs.
[0020] The front-end unit 210 converts part of the source program into an intermediate representation and causes the obtained intermediate representation to be executed by the back-end unit 240. In addition, the front-end unit 210 executes the part of the source program that is not converted into the intermediate representation by executing the source program. The front-end unit 210 is an example of an intermediate representation generating means.
[0021] An example of a portion of the source program that the front-end unit 210 executes during execution of the source program without converting it into an intermediate representation is a predetermined instruction included in the source program that is scheduled to be executed in the source program. For example, the front-end unit 210 may execute a display instruction (e.g., a "print" statement) included in the source program in the source program.
[0022] The intermediate representation generated by the front-end unit 210 is not executed immediately upon generation, but is executed when the need arises. Execution of the intermediate representation in this case is also called deferred execution. For example, consider a case where a source program includes a sequence (a series of instructions) for calculating the value of a variable f and an instruction "print(f)" for displaying the value of the variable f. In this case, the front-end unit 210 generates an intermediate representation of the sequence for calculating the value of the variable f, but the intermediate representation is not executed when the intermediate representation is generated. Then, during execution of the source program, at the timing when the instruction for displaying the value of the variable f is executed, the back-end unit 240 executes the intermediate representation of the sequence for calculating the value of the variable f using the child library 250. Obtaining the value of a variable, operation, etc. is called evaluating the variable, operation, etc. The front-end unit 210 requests the back-end unit 240 to execute the intermediate representation in order to evaluate the variable, operation, etc.
[0023] The parent library 220 is a library that corresponds to the programming language of the source program. The front-end unit 210 uses the parent library 220 to execute the part of the source program that is to be executed by the source program.
[0024] The optimization unit 230 performs optimization processing on the intermediate representation generated by the front-end unit 210. For example, the arithmetic device 100 may function as a domain-specific compiler that performs compilation for a specific domain, such as matrix calculations in a source program, and the optimization unit 230 may perform optimization processing on the intermediate representation using knowledge about the specific domain.
[0025] Figure 2 shows an example of a source program. Figure 2 shows a program that performs the matrix calculation "f = (a + b) * (a + c)" and displays the value of the matrix f. "*" represents matrix multiplication. "+" represents matrix addition. "mat_mul" represents matrix multiplication, and "mat_add" represents matrix addition. All of "mat_mul," "mat_add," and "mat_print" are assumed to be provided by the parent library 220.
[0026] "a", "b", and "c" are all variables that represent matrices, and their values are assumed to be fixed by the time the program shown in Figure 2 is executed. "d", "e", and "f" are also variables that represent matrices. "mat_print(f)" indicates that the value of the variable f is to be displayed.
[0027] Fig. 3 is a diagram showing an example of an intermediate representation. Fig. 3 shows an example in which the front-end unit 210 expresses the intermediate representation obtained by converting the source program shown in Fig. 2 in the form of a program. The intermediate representation expressed in the form of a program is also called an intermediate program or intermediate code. The front-end unit 210 may generate an intermediate representation of a tree structure that indicates the reference relationships of data, and output the part of the intermediate representation of the tree structure that corresponds to the calculation of the desired value as intermediate code.
[0028] Of the source program shown in Fig. 2, "mat_print(f)" is executed by the front-end unit 210 in the source program. The front-end unit 210 converts "d = mat_mul(a, b)", "e = mat_mul(a, c)", and "f = mat_add(d, e)" of the source program shown in Fig. 2 into an intermediate representation. Fig. 3 shows the intermediate representation for performing the matrix calculation "f = (a + b) * (a + c)".
[0029] 3, "mul" represents matrix multiplication in the intermediate representation, which corresponds to "mat_mul" in the source program. "add" represents matrix addition in the intermediate representation, which corresponds to "mat_add" in the source program. Both "mul" and "add" are assumed to be provided by the child library 250.
[0030] "%a" represents the variable corresponding to variable a in Figure 2. "%b" represents the variable corresponding to variable b in Figure 2. "%c" represents the variable corresponding to variable c in Figure 2. "%d" represents the variable corresponding to variable d in Figure 2. "%e" represents the variable corresponding to variable e in Figure 2. "%f" represents the variable corresponding to variable f in Figure 2.
[0031] Fig. 4 is a diagram showing an example of an intermediate representation obtained by the optimization process performed by the optimization unit 230. Fig. 4 shows an example of an intermediate representation obtained by performing the optimization process by the optimization unit 230 on the intermediate representation shown in Fig. 3. Figure 4 shows the intermediate representation for the matrix calculation "f = a * (b + c)." "%temp = add(%b, %c)" adds the variables "%b" and "%c," which represent matrices, and inputs the result into the variable "%temp." "%f = mul (%a, %temp)" multiplies the variables "%a" and "%temp," which represent matrices, and inputs the result into the variable "%f."
[0032] The intermediate representation shown in Fig. 4 can be said to be an optimization of the intermediate representation shown in Fig. 3 by the optimizer 230 using knowledge about the matrix domain, that is, knowledge that the distributive law holds for matrices. The intermediate representation shown in Fig. 4 has one less multiplication than the intermediate representation shown in Fig. 3.
[0033] The conversion possibility determination unit 231 detects a part that can be converted by optimization from the intermediate representation generated by the front-end unit 210. The conversion possibility determination unit 231 corresponds to an example of a conversion possibility determination means. Depending on the data reference relationships in the intermediate representation, there may be cases where optimization processing cannot be applied to the intermediate representation, or where the desired effect cannot be obtained even if optimization processing is applied.
[0034] Figure 5 shows an example of a source program that is not suitable for optimization. In the source program shown in Figure 5, "mat_print(e)" is added after the source program shown in Figure 2, indicating that the value of the variable e is to be displayed. In the source program shown in Figure 2, only the value of variable f is displayed, whereas in the source program shown in Figure 5, the value of variable e is also displayed in addition to the value of variable f.
[0035] Now, let us consider a case where the intermediate representation shown in Figure 3 is generated for the source program shown in Figure 5 and then optimized to produce the intermediate representation shown in Figure 4. In this case, "%e = mul(%a, %c)" is no longer present in the intermediate representation shown in Figure 4, and the value of the variable e cannot be obtained when "mat_print(e)" is executed in the source program of Figure 5.
[0036] Therefore, it is necessary to either treat "mat_print(e)" as an error, or to insert the calculation "%e = mul(%a, %c)" into the optimized intermediate representation. If "mat_print(e)" is treated as an error, it will be a burden for the user, as the user may not be able to display the value of the variable e as desired, or it may be necessary to impose restrictions on how the program is written to prevent errors from occurring. If the calculation "%e = mul(%a, %c)" is inserted into the intermediate representation after optimization, the effect of reducing the number of calculations will not be obtained, and the processing time will be longer due to the time it takes to rewrite the intermediate representation during optimization.
[0037] 5 shows an example in which a variable is referenced by the display command "mat_print(e)", but the same applies when a variable is referenced by an operation rather than an instruction. For example, if the source program shown in FIG. 5 includes the operation "g = add(e, e)" instead of "mat_print(e)" and the value of the variable g is evaluated, optimizing the intermediate representation will result in the same inconvenience as described above.
[0038] Therefore, the conversion possibility determination unit 231 detects a portion of the intermediate representation generated by the front-end unit 210 that will not cause the inconvenience of being unable to refer to the above-mentioned data even if conversion such as optimization is performed. A portion of the intermediate representation that will not cause the inconvenience of being unable to refer to the above-mentioned data even if conversion is performed is also referred to as a portion that can be converted to another operation, or simply a convertible portion. The specific processing performed by the conversion possibility determination unit 231 will be described later.
[0039] The conversion unit 232 performs optimization on a portion of the intermediate representation generated by the front-end unit 210 that is detected as a convertible portion by the conversion possibility determination unit 231. The optimization performed by the conversion unit 232 is not limited to a specific type. If the conversion possibility determination unit 231 is unable to detect a convertible part, or if there is no optimization that can be applied to a part that the conversion possibility determination unit 231 detects as a convertible part, the conversion unit 232 does not convert the intermediate representation.
[0040] The back-end unit 240 executes the intermediate representation. As described above, when the front-end unit 210 generates the intermediate representation, the back-end unit 240 does not execute the intermediate representation. When the front-end unit 210 executes the source program and requests the back-end unit 240 to execute the intermediate representation in order to evaluate variables, operations, etc., the back-end unit 240 executes the intermediate representation in response to the request from the front-end unit 210.
[0041] The child library 250 is a library corresponding to the programming language of the intermediate code. The back-end unit 240 acquires the intermediate representation expressed in the form of intermediate code from the optimization unit 230 and executes the acquired intermediate representation using the child library 250.
[0042] FIG. 6 is a diagram showing an example of a procedure for the conversion possibility determination unit 231 to detect convertible parts in the intermediate representation. The conversion possibility determination unit 231 performs processing to detect convertible parts for objects in the source program.
[0043] An object here abstractly represents data that appears in the execution of a program, or the storage area for that data. Selecting an object in a source program can be viewed as selecting a variable in the intermediate representation that corresponds to that object, and further, as selecting an operation to calculate the value of that variable.
[0044] Therefore, it can be said that the conversion possibility determination unit 231 detects convertible parts of objects in the source program, and thereby detects operations that can be converted into other operations among the operations included in the intermediate representation. Operations that can be converted into other operations correspond to the above-mentioned parts that can be converted into other operations.
[0045] Here, when the front-end unit 210 executes a source program, an intermediate representation is generated without actually performing an operation during calculation in the source program (when a library function of the parent library 220 is called). For this reason, the front-end unit 210 assigns a Future type object, which represents an intermediate state, to data such as variables handled during the execution of the source program.
[0046] The Future type is expressed as "class Future{op, result}", for example. "result" stores the actual data. "result" is undefined until the actual operation is performed. "op" indicates information about the instruction that calculates "result". For example, "op" indicates the operation name (type of operation), such as "mat_mul" or "mat_add" in the source program shown in Figure 2.
[0047] (Step S111) The conversion possibility determination unit 231 selects an object to be determined as to whether it is convertible from among the objects in the source program. The conversion possibility determination unit 231 selects an object indicating an output variable as the object to be determined as to whether it is convertible. The output variable here is a variable indicating a value obtained by executing the program.
[0048] In the case of the source program shown in FIG. 2, the objects representing the variables d, e, and f shown on the left side of the equation representing the assignment statement are examples of objects to be determined as to whether they can be converted. In the following, objects that represent variables will also be represented by the name of the variable. For example, in the source program shown in Figure 2, the object that represents variable a will also be written as object a. The object that represents variable b will also be written as object b. The object that represents variable c will also be written as object c. The object that represents variable d will also be written as object d. The object that represents variable e will also be written as object e. The object that represents variable f will also be written as object f.
[0049] In the case of the source program shown in FIG. 2, the conversion possibility determining unit 231 selects objects d, e, and f as objects to be determined. The conversion possibility determination unit 231 classifies the objects selected as the determination target in step S111 into objects whose values need to be acquired at the time of evaluation and objects whose values do not need to be acquired at the time of evaluation.
[0050] An object whose value needs to be acquired during evaluation corresponds to a part of the intermediate representation that cannot be converted to another representation. The need to acquire a value during evaluation is also referred to as an acquisition requirement. An object whose value does not need to be acquired during evaluation corresponds to a part of the intermediate representation that can be converted to another representation. The fact that the value does not need to be acquired during evaluation is also referred to as "acquisition-free."
[0051] Below, examples of the classification status of objects by the conversion possibility determination unit 231 are as follows: Target[], Required[], Unnecessary[] It is expressed as follows. Within the [ ] of target [ ], objects that have not been classified as to whether or not a value needs to be acquired at the time of evaluation, among the objects selected by the conversion possibility determination unit 231 as objects to be determined, are shown by variable name. Within the [ ] of necessary [ ], objects that the conversion possibility determination unit 231 has classified as objects that need to be acquired are shown by variable name. Within the [ ] of unnecessary [ ], objects that the conversion possibility determination unit 231 has classified as objects that do not need to be acquired are shown by variable name.
[0052] In the case of the source program shown in FIG. 2, the classification status of the objects when the conversion possibility determination unit 231 executes the process of step S111 is as follows: Target [d,e,f], Required [], Unnecessary [] It is expressed as follows. After step S111, the process proceeds to step S121.
[0053] (Step S121) The conversion possibility determination unit 231 classifies the object that triggered the evaluation as one that needs to be acquired. The object that triggered the evaluation is an object whose value is required during the execution of the source program. The front-end unit 210 causes the back-end unit 240 to execute the intermediate representation to obtain the value of that object. In the case of the source program shown in Figure 2, the object f indicating the variable f referenced by "mat_print(f)" is an example of an object that triggered the evaluation.
[0054] In the case of the source program shown in FIG. 2, the classification status of the objects when the conversion possibility determination unit 231 executes the process of step S121 is as follows: Target [d,e], Required [f], Unnecessary [] It is expressed as follows. After step S121, the process proceeds to step S122.
[0055] (Step S122) The conversion possibility determination unit 231 determines whether or not there are any unclassified objects remaining. If the conversion possibility determination unit 231 determines that an unclassified object remains (step S122: YES), the process proceeds to step S131. On the other hand, if it determines that an unclassified object does not remain (step S122: NO), the conversion possibility determination unit 231 ends the process of FIG.
[0056] (Step S131) The conversion possibility determination unit 231 acquires the value of the reference counter of each object to be determined, and classifies an object whose reference counter value is 1 or less as not requiring acquisition. After step S131, the process proceeds to step S132.
[0057] The process in step S131 will be further described. A reference counter is provided for each object and counts the number of times that object is referenced in the source program. Specifically, the reference counter counts the number of pointers attached to the object. In reference-counted programming languages, reference counters are used to manage the lifetime of objects. In particular, when an object's reference counter reaches zero, its memory is freed.
[0058] 7 is a diagram illustrating a first example of the value of the reference counter in the source program shown in FIG. Object o11 is a Future type object that indicates the calculation result of "mat_add(d, e)". In the explanation of the process performed by the conversion possibility determination unit 231, the object o11 is represented by the variable name "f".
[0059] In the source program shown in Figure 2, object o11 is referenced from variable f in both "f = mat_add(d, e)" and "mat_print(f)". In the example in Figure 7, the value of the reference counter for object o11 is 1.
[0060] The object o12 is a Future type object that indicates the calculation result of "mat_mul(a, b)". In the explanation of the process performed by the conversion possibility determination unit 231, the object o12 is represented by the variable name "d".
[0061] In the source program shown in Figure 2, object o12 is referenced from variable d in "d = mat_mul(a, b)" and also from the argument of "f = mat_add(d, e)" (variable arg0 in the example in Figure 7). In the example in Figure 7, the value of the reference counter of object o12 is 2.
[0062] The object o13 is a Future type object that indicates the calculation result of "mat_mul(a, c)". In the explanation of the process performed by the conversion possibility determination unit 231, the object o13 is represented by the variable name "e".
[0063] In the source program shown in Figure 2, object o13 is referenced from variable e in "e = mat_mul(a, c)" and also from the argument of "f = mat_add(d, e)" (variable arg1 in the example in Figure 7). In the example in Figure 7, the value of the reference counter of object o13 is 2.
[0064] Of the unclassified objects, the conversion possibility determination unit 231 classifies objects whose reference counter value is 1 or less as objects not requiring acquisition. On the other hand, the conversion possibility determination unit 231 leaves objects whose reference counter value is 2 or more as unclassified in the processing of step S131. The reason for using 1 instead of 0 as the criterion is to take into account the internal reference of the object.
[0065] In the case of the source program shown in FIG. 2, the classification status of the object when the conversion possibility determination unit 231 executes the process of step S131 is as follows: Target [d,e], Required [f], Unnecessary [] It will remain as it is.
[0066] FIG. 8 is a diagram showing an example of a source program in which functions are directly written in the arguments of the functions. In the source program shown in Figure 2, the calculation result of "mat_mul(a, b)" is assigned to variable d, and the calculation result of "mat_mul(a, c)" is assigned to variable e. Then, in the calculation of "mat_add(e, f)", the values of variables d and e are read.
[0067] In contrast to this, in the source program shown in Figure 8, "mat_mul(a, b)" and "mat_mul(a, c)" are written directly as arguments to "mat_add" as follows: "mat_add(mat_mul(a, b), mat_mul(a, c))". In the source program shown in Figure 8, the values of "mat_mul(a, b)" and "mat_mul(a, c)" are used as arguments to "mat_add" to perform the calculation of this "mat_add".
[0068] 9 is a diagram showing a second example of the value of the reference counter. FIG. 9 shows an example of the value of the reference counter in the source program shown in FIG. The object o21 is a Future type object that indicates the calculation result of "mat_add(mat_mul(a, b), mat_mul(a, c))".
[0069] In the source program shown in Figure 8, object o2 is referenced from variable f in both "f = mat_add(mat_mul(a, b), mat_mul(a, c))" and "mat_print(f)". In the example in Figure 9, the value of the reference counter for object o21 is 1.
[0070] The object o22 is a Future type object that indicates the calculation result of "mat_mul(a, b)". In the source program shown in Figure 8, one reference to object o22 is counted: obtaining the value of "mat_mul(a, b)" in "f = mat_add(mat_mul(a, b), mat_mul(a, c))". In the example in Figure 9, this reference is represented as a reference from variable arg0. In the example in Figure 9, the value of the reference counter for object o22 is 1.
[0071] The object o23 is a Future type object that indicates the calculation result of "mat_mul(a, c)". In the source program shown in Figure 8, one reference to object o23 is counted: obtaining the value of "mat_mul(a, c)" in "f = mat_add(mat_mul(a, b), mat_mul(a, c))". In the example in Figure 9, this reference is represented as a reference from variable arg1. In the example in Figure 9, the value of the reference counter for object o23 is 1.
[0072] When the reference counter value is 1, as in the case of object o22, even if the intermediate representation corresponding to the part where the reference is made is rewritten, the reference will not be made in other parts, and the above-mentioned inconvenience will not occur. Therefore, in step S103 of Fig. 6, the conversion feasibility determination unit 231 can classify an object whose reference counter value is 1 as one that does not need to be acquired, without having to perform step S104 and the subsequent processes.
[0073] (Step S132) The conversion possibility determination unit 231 determines whether or not there are any unclassified objects remaining. If the conversion possibility determination unit 231 determines that an unclassified object remains (step S132: YES), the process proceeds to step S141. On the other hand, if it determines that an unclassified object does not remain (step S132: NO), the conversion possibility determination unit 231 ends the process of FIG.
[0074] (Step S141) The conversion possibility determination unit 231 performs processing to identify the stack frame of the function that called the instruction that triggered the evaluation. Here, we assume that the source program is written in the form that the main program calls functions, and that when a function is called, information about the called function is stored in the stack. We also assume that information about the main program is initially stored in the stack. A stack frame is information about the main program and each individual function stored in the stack.
[0075] In the source program shown in Figure 2, "mat_print(f)" is an example of an instruction that triggers evaluation. The function or main program that includes the source program shown in Figure 2 is an example of a function that calls the instruction that triggers evaluation. After step S141, the process proceeds to step S142.
[0076] (Step S142) The conversion possibility determination unit 231 determines whether or not a stack frame has been identified in the process of step S141. If the conversion possibility determination unit 231 determines that the stack frame has been identified (step S142: YES), the process proceeds to step S151. On the other hand, if the conversion possibility determination unit 231 determines that the stack frame has not been identified (step S142: NO), the process proceeds to step S171.
[0077] (Step S151) The conversion possibility determination unit 231 classifies an object whose reference counter value is greater than the number of times the object is referenced by a local variable in the function that called the instruction that triggered the evaluation, which is shown in the stack frame, +1 as an object that needs to be acquired.
[0078] In the case of the source program shown in FIG. 2, there is no object classified as needing to be acquired in step S152, and the classification status of the object when the conversion possibility determination unit 231 executes the process of step S131 is as follows: Target [d,e], Required [f], Unnecessary [] It will remain as it is. After step S151, the process proceeds to step S152.
[0079] The process in step S151 will be further described. As mentioned above, a stack frame is information about one function that is stored on the stack when a function is called. The stack frame stores the local variables of the called function, the base address (ebp) of the stack frame of the previous function (the calling function), the return address of the called function, the arguments of the called function, etc.
[0080] In the process of step S151, the conversion possibility determination unit 231 uses information on local variables included in the stack frame to determine whether a reference to an object from a variable within a function is a reference from a local variable or a reference from a global variable. Then, for each unclassified object, the conversion possibility determination unit 231 compares the value obtained by adding 1 to the number of references from local variables with the value of the reference counter. Adding 1 to the number of references from local variables takes into account internal references to the object.
[0081] FIG. 10 is a diagram showing an example of a source program in which values are assigned to global variables. In the example of FIG. 10, the function "mma" and the function "foo" are shown.
[0082] Looking at the variable d, the calculation result of "mat_mul(a, b)" is assigned to the variable d in the function "mma" with "d = mat_mul(a, b)". Also, the variable d is passed to the function foo with "foo(d)". The variable d passed to the function "foo" is assigned to the global variable y within the function "foo".
[0083] In addition, in the function "mma", references to object d appear in three places: "d = mat_mul(a, b)", "f = mat_add(d, e)", and "foo(d)". The value of the reference counter for object d is 3. In the function "mma", the reference to object e appears in two places: "e = mat_mul(a, c)" and "f = mat_add(d, e)". The value of the reference counter for object e is 2. In the function "mma", the reference to object f appears in two places: "f = mat_add(d, e)" and "mat_print(f)". The value of the reference counter for object f is 2.
[0084] Comparing the value of the reference counter with the above value calculated by referencing the stack frame, for object d, the value of the reference counter is 3, while the value calculated by referencing the stack frame is 1. Because the former value is greater than the latter value, it can be determined that the reference to object d from a variable may include a reference from a global variable. In this case, there is a possibility that object d may be referenced outside the function "mma", and the conversion possibility determination unit 231 classifies object d as needing to be acquired.
[0085] On the other hand, for object e, the value of the reference counter is 2, and the value calculated by referencing the stack frame is also 2. Since the two values are equal, it can be determined that the reference to object e from the variable is a reference from a local variable. In this case, the conversion possibility determination unit 231 leaves object e unclassified in step S151.
[0086] For object f, the value of the reference counter is 2, and the value calculated by referencing the stack frame is also 2. Since the two values are equal, it can be determined that the reference to object e from the variable is a reference from a local variable. In this case, the conversion possibility determination unit 231 leaves object f unclassified in step S151.
[0087] (Step S152) The conversion possibility determination unit 231 determines whether or not there are any unclassified objects remaining. If the conversion possibility determination unit 231 determines that an unclassified object remains (step S152: YES), the process proceeds to step S161. On the other hand, if it determines that an unclassified object does not remain (step S152: NO), the conversion possibility determination unit 231 ends the process of FIG.
[0088] (Step S161) The conversion possibility determination unit 231 determines whether or not there is a reference after evaluation for each unclassified object from the source code of the function that called the function to be evaluated and the instruction sequence. The conversion possibility determination unit 231 classifies an object that is determined to have no reference after evaluation as one that does not need to be acquired.
[0089] 2, neither object d nor e has a reference to these objects after "mat_print(f)." As a result, the conversion possibility determination unit 231 classifies objects d and e as objects that do not need to be acquired. The classification status of the object when the conversion possibility determination unit 231 executes the process of step S161 is as follows: Target [], Required [f], Unnecessary [d,e] It is expressed as follows. After step S161, the process proceeds to step S171.
[0090] The process in step S161 will be further described. FIG. 11 is a diagram showing an example of a source program with no references after evaluation. In the example shown in FIG. 11, it is assumed that objects d and e remain as unclassified objects.
[0091] 11, the instruction to be evaluated, "mat_print(f)," is immediately followed by "return," and neither object d nor object e is referenced after evaluation. In this case, the conversion possibility determination unit 231 classifies objects d and e as objects that do not need to be acquired.
[0092] FIG. 12 is a diagram showing an example of a source program with an evaluated reference. In the example shown in FIG. 12, it is assumed that object d remains as an unclassified object. 12, the instruction to be evaluated, "mat_print(f)," is followed by "mat_print(e)," which references object e. In this case, the conversion possibility determination unit 231 leaves object e unclassified.
[0093] In addition, the conversion possibility determination unit 231 classifies the objects that remain unclassified in the processes up to step S161 into objects that need to be acquired in step S171. In step S161, the conversion possibility determination unit 231 also leaves the unclassified object as unclassified if the evaluated code cannot be analyzed, if the analysis would be costly, or if the source code cannot be accessed.
[0094] (Step S171) The conversion possibility determination unit 231 classifies all unclassified objects as objects that need to be acquired. For objects for which it was not possible to determine whether the result is necessary, the conversion possibility determination unit 231 classifies the objects as objects that need to be acquired, taking a safer approach to avoid errors or other inconveniences. After step S171, the conversion possibility determination unit 231 ends the processing of FIG.
[0095] As described above, the front-end unit 210 generates an intermediate representation corresponding to a portion of the source program, which is the program to be executed. The conversion feasibility determination unit 231 determines that, among the operations indicated in the intermediate representation, an operation in which the object corresponding to the result of that operation is referenced once or less in the source program can be converted into another operation. The conversion unit 232 performs processing to convert the intermediate representation based on the determination result of whether the operation can be converted into another operation. The back-end unit 240 executes the intermediate representation processed by the conversion means.
[0096] The arithmetic device 100 can determine whether an operation represented in an intermediate representation can be converted into another operation based on the relatively simple process of counting the number of times an object is referenced in a source program. In this respect, the arithmetic device 100 can detect, with a relatively small load, a portion of the intermediate representation that can be converted into another operation.
[0097] In addition, the conversion possibility determination unit 231 counts the number of times the result of an operation in the source program is referenced, for each object representing data handled in the execution of the source program, using a reference counter used to manage the lifetime of the object.
[0098] According to the arithmetic device 100, it is possible to determine whether an operation represented in an intermediate representation can be converted into another operation by using a reference counter provided for managing objects. In this respect, according to the arithmetic device 100, there is no need to provide a separate mechanism for counting the number of references to an object.
[0099] Furthermore, the conversion possibility determination unit 231 determines that an operation represented by an intermediate representation in which an object corresponding to the result of the operation is referenced more than once in the source program, and in which the number of times the object is referenced is greater than the number of times the object is referenced from a local variable plus one, cannot be converted into another operation. According to the arithmetic device 100, even for a source program that uses global variables, it is possible to determine whether or not an operation represented in an intermediate representation can be converted into another operation.
[0100] Furthermore, the conversion possibility determination unit 231 refers to the stack frame of the function in the source program and acquires information indicating the local variables in the function. According to the arithmetic device 100, information indicating whether a variable is a local variable or a global variable can be obtained by the relatively simple process of referencing the stack frame.
[0101] Furthermore, if the conversion feasibility determination unit 231 cannot identify the stack frame of the function that called the instruction that triggers the execution of the intermediate representation in the source program, it determines that an operation indicated in the intermediate representation and in which the object corresponding to the result of that operation is referenced more than once in the source program cannot be converted to another operation. According to the arithmetic device 100, when desired information cannot be obtained from the stack frame, it is possible to make a conservative determination such that a part of the intermediate representation cannot be converted into another operation.
[0102] In addition, the conversion possibility determination unit 231 determines that an operation in a source program, which is a function that calls an instruction that triggers the execution of the intermediate representation, and which corresponds to an object that is not referenced after the instruction is called, can be converted into another operation. According to the arithmetic device 100, it is possible to determine in more detail whether an operation represented in an intermediate representation can be converted into another operation.
[0103] Furthermore, the conversion possibility determination unit 231 determines that an operation, among operations represented in the intermediate representation, for which it is not yet determined whether it can be converted into another operation, cannot be converted into another operation. According to the arithmetic device 100, it is possible to make a conservative determination such that, for an operation whose conversion into another operation is not yet determined, it is determined that the operation cannot be converted into another operation.
[0104] 13 is a diagram showing another example of the configuration of a arithmetic device according to the embodiment. In the configuration shown in Fig. 13, a arithmetic device 610 includes an intermediate representation generation unit 611, a conversion feasibility determination unit 612, a conversion unit 613, and an intermediate representation execution unit 614.
[0105] With this configuration, the intermediate representation generation unit 611 generates an intermediate representation that corresponds to a part of the source program, which is the program to be executed. The conversion possibility determination unit 612 determines that, among the operations represented in the intermediate representation, an operation in which the object corresponding to the result of that operation is referenced once or less in the source program can be converted into another operation. The conversion unit 613 performs processing to convert the intermediate representation based on the result of the determination as to whether the operation can be converted into another operation. The intermediate representation execution unit 614 executes the intermediate representation processed by the conversion unit 613. The intermediate representation generation unit 611 corresponds to an example of intermediate representation generation means. The conversion feasibility determination unit 612 corresponds to an example of conversion feasibility determination means. The conversion unit 613 corresponds to an example of conversion means. The intermediate representation execution unit 614 corresponds to an example of intermediate representation execution means.
[0106] The arithmetic unit 610 can determine whether an operation represented in the intermediate representation can be converted into another operation based on the relatively simple process of counting the number of times an object is referenced in the source program. In this respect, the arithmetic unit 610 can detect, with a relatively small load, portions of the intermediate representation that can be converted into other operations.
[0107] Fig. 14 is a diagram showing an example of a processing procedure in the calculation method according to the embodiment. The calculation method shown in Fig. 14 includes generating an intermediate representation (step S611), determining whether conversion is possible (step S612), performing the conversion (step S613), and executing the intermediate representation (step S614).
[0108] In generating an intermediate representation (step S611), the computer generates an intermediate representation corresponding to a part of the source program, which is the program to be executed. In determining whether conversion is possible (step S612), the computer determines that an operation represented in the intermediate representation, in which the object corresponding to the result of that operation is referenced once or less in the source program, can be converted into another operation. In performing the conversion (step S613), the computer performs processing to convert the intermediate representation based on the result of determining whether or not the intermediate representation can be converted into another operation. In executing the intermediate representation (step S614), the computer executes the processed intermediate representation to transform the intermediate representation.
[0109] The calculation method shown in Fig. 14 can determine whether an operation represented in an intermediate representation can be converted into another operation based on the relatively simple process of counting the number of times an object is referenced in a source program. In this respect, the calculation method shown in Fig. 14 can detect parts of the intermediate representation that can be converted into another operation with a relatively small load.
[0110] FIG. 15 is a schematic block diagram illustrating the configuration of a computer according to at least one embodiment. In the configuration shown in FIG. 15, a computer 700 includes a CPU 710, a main memory device 720, an auxiliary memory device 730, an interface 740, and a non-volatile recording medium 750.
[0111] One or more of the above-described arithmetic device 100 and arithmetic device 610, or a part thereof, may be implemented in a computer 700. In this case, the operation of each of the above-described processing units is stored in the auxiliary storage device 730 in the form of a program. The CPU 710 reads the program from the auxiliary storage device 730, loads it into the main storage device 720, and executes the above-described processing in accordance with the program. The CPU 710 also allocates storage areas in the main storage device 720 corresponding to each of the above-described storage units in accordance with the program. Communication between each device and other devices is performed by an interface 740 having a communication function and performing communication under the control of the CPU 710.
[0112] When the arithmetic device 100 is implemented in a computer 700, the operations of the control unit 190 and each of its units are stored in the form of a program in an auxiliary storage device 730. The CPU 710 reads the program from the auxiliary storage device 730, loads it into the main storage device 720, and executes the above-described processing in accordance with the program.
[0113] Furthermore, the CPU 710 allocates a storage area for the storage unit 180 in the main storage device 720 in accordance with the program. Communication between the arithmetic device 100 and other devices is performed by the interface 740, which has a communication function and operates under the control of the CPU 710. Interaction between the arithmetic device 100 and a user is performed by the interface 740, which has a display device and an input device, displaying various images under the control of the CPU 710 and accepting user operations.
[0114] When the calculation device 610 is implemented in the computer 700, the operations of the intermediate representation generation unit 611, the conversion feasibility determination unit 612, the conversion unit 613, and the intermediate representation execution unit 614 are stored in the form of programs in the auxiliary storage device 730. The CPU 710 reads the programs from the auxiliary storage device 730, loads them into the main storage device 720, and executes the above-mentioned processes in accordance with the programs.
[0115] Furthermore, the CPU 710 allocates a storage area in the main memory device 720 for the arithmetic device 610 to perform processing in accordance with the program. Communication between the arithmetic device 610 and other devices is performed by an interface 740 having a communication function and operating under the control of the CPU 710. Interaction between the arithmetic device 610 and a user is performed by the interface 740 having a display device and an input device, which displays various images under the control of the CPU 710 and accepts user operations.
[0116] One or more of the above-described programs may be recorded on nonvolatile recording medium 750. In this case, interface 740 may read the programs from nonvolatile recording medium 750. CPU 710 may then directly execute the programs read by interface 740, or may temporarily store the programs in main storage device 720 or auxiliary storage device 730 and then execute them.
[0117] Note that a program for executing all or part of the processing performed by arithmetic device 100 and arithmetic device 610 may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be read into a computer system and executed to perform the processing of each unit. Note that the term "computer system" here includes an OS (Operating System) and hardware such as peripheral devices. Furthermore, "computer-readable recording media" refers to portable media such as flexible disks, optical magnetic disks, ROMs (Read Only Memory), and CD-ROMs (Compact Disc Read Only Memory), as well as storage devices such as hard disks built into computer systems. The program may be one that realizes part of the aforementioned functions, or may be one that can realize the aforementioned functions in combination with a program already stored in the computer system.
[0118] Although an embodiment of the present invention has been described above in detail with reference to the drawings, the specific configuration is not limited to this embodiment, and includes designs within the scope of the gist of the present invention.
[0119] A part or all of the above-described embodiments can be described as, but not limited to, the following supplementary notes.
[0120] (Appendix 1) an intermediate representation generating means for generating an intermediate representation corresponding to a part of a source program that is a program to be executed; a conversion possibility determination means for determining that an operation represented by the intermediate representation, which has an object corresponding to the result of the operation referenced once or less in the source program, can be converted into another operation; a conversion means for converting the intermediate representation based on a result of determining whether the intermediate representation can be converted into another operation; an intermediate representation execution means for executing the intermediate representation processed by the conversion means; A computing device comprising:
[0121] (Appendix 2) the conversion possibility determination means counts, for each object representing data handled in the execution of the source program, the number of times a result of an operation in the source program is referenced, using a reference counter used to manage the lifetime of the object; 10. The computing device of claim 1.
[0122] (Appendix 3) the conversion possibility determining means determines that an operation represented by the intermediate representation and having an object corresponding to the result of the operation referenced more than once in the source program, the object being referenced more than the number of times that the object is referenced from a local variable plus one, cannot be converted into another operation; 10. The computing device of claim 1 or 2.
[0123] (Appendix 4) the conversion possibility determination means refers to a stack frame of a function in the source program and acquires information indicating local variables in the function; 4. The computing device of claim 3.
[0124] (Appendix 5) when the conversion possibility determination unit cannot identify a stack frame of a function that is a caller of an instruction that triggers execution of the intermediate representation in the source program, the conversion possibility determination unit determines that an operation that is represented by the intermediate representation and in which an object corresponding to the result of the operation is referenced more than once in the source program cannot be converted into another operation; 5. The computing device of claim 4.
[0125] (Appendix 6) the conversion possibility determination means determines that an operation corresponding to an object that is not referenced after the call of an instruction that triggers the execution of the intermediate representation in the source program can be converted into another operation; 6. The computing device of claim 5.
[0126] (Appendix 7) the conversion possibility determination means determines, among the operations represented in the intermediate representation, an operation whose conversion possibility to another operation is not yet determined, as being inconvertible to another operation; 7. The computing device of claim 6.
[0127] (Appendix 8) The computer Generate an intermediate representation corresponding to a portion of the source program to be executed; determining that an operation represented by the intermediate representation, which has an object corresponding to the result of the operation referenced once or less in the source program, can be converted into another operation; performing a process for converting the intermediate representation based on a result of determining whether the intermediate representation can be converted into another operation; Executing the processed intermediate representation to transform the intermediate representation; A calculation method including:
[0128] (Appendix 9) On the computer, generating an intermediate representation corresponding to a portion of a source program to be executed; determining that an operation represented by the intermediate representation, which has an object corresponding to the result of the operation referenced once or less in the source program, can be converted into another operation; performing a process for converting the intermediate representation based on a result of determining whether the intermediate representation can be converted into another operation; executing the processed intermediate representation to transform the intermediate representation; A recording medium that records a program for executing the program. [Industrial Applicability]
[0129] The present invention may be applied to a computing device, a computing method, and a recording medium. [Explanation of symbols]
[0130] 100, 610 arithmetic unit 110 Communications Department 120 Display section 130 Operation input section 180 Storage section 190 Control Unit 210 Front end 220 Parent Library 230 Optimization Department 231, 612 Conversion possibility determination section 232, 613 conversion unit 240 Backend 250 child libraries 611 Intermediate representation generator 614 Intermediate Representation Execution Unit
Claims
1. an intermediate representation generating means for generating an intermediate representation corresponding to a part of a source program that is a program to be executed; a conversion possibility determination means for determining that an operation represented by the intermediate representation, which has an object corresponding to the result of the operation referenced once or less in the source program, can be converted into another operation; a conversion means for converting the intermediate representation based on a result of determining whether the intermediate representation can be converted into another operation; an intermediate representation execution means for executing the intermediate representation processed by the conversion means; A computing device comprising:
2. the conversion possibility determination means counts, for each object representing data handled in the execution of the source program, the number of times a result of an operation in the source program is referenced, using a reference counter used to manage the lifetime of the object; The computing device of claim 1 .
3. the conversion possibility determining means determines that an operation represented by the intermediate representation and having an object corresponding to the result of the operation referenced more than once in the source program, the object being referenced more than the number of times that the object is referenced from a local variable plus one, cannot be converted into another operation; 3. The computing device according to claim 1 or claim 2.
4. the conversion possibility determination means refers to a stack frame of a function in the source program and acquires information indicating local variables in the function; The computing device according to claim 3 .
5. When the conversion possibility determination means cannot identify a stack frame of a function that is a caller of an instruction that triggers execution of the intermediate representation in the source program, it determines that an operation that is represented by the intermediate representation and in which an object corresponding to the result of the operation is referenced more than once in the source program cannot be converted into another operation. The computing device according to claim 4.
6. the conversion possibility determination means determines that an operation corresponding to an object that is not referenced after the call of an instruction that triggers the execution of the intermediate representation in the source program can be converted into another operation; The computing device according to claim 5 .
7. the conversion possibility determination means determines, among the operations represented in the intermediate representation, an operation whose conversion possibility to another operation is not yet determined, as being inconvertible to another operation; The computing device according to claim 6.
8. The computer Generate an intermediate representation corresponding to a portion of the source program to be executed; determining that an operation represented by the intermediate representation, which has an object corresponding to the result of the operation referenced once or less in the source program, can be converted into another operation; performing a process for converting the intermediate representation based on a result of determining whether the intermediate representation can be converted into another operation; Executing the processed intermediate representation to transform the intermediate representation; A calculation method including:
9. On the computer, generating an intermediate representation corresponding to a portion of a source program to be executed; determining that an operation represented by the intermediate representation, which has an object corresponding to the result of the operation referenced once or less in the source program, can be converted into another operation; performing a process for converting the intermediate representation based on a result of determining whether the intermediate representation can be converted into another operation; executing the processed intermediate representation to transform the intermediate representation; A program to execute.
Citation Information
Patent Citations
Program code conversion method
JP2002527815A
Program conversion device and program conversion method
JP2014219858A
Optimizing intermediate representation of script code by eliminating redundant reference count operations
US20140317607A1