JP2011028523A - Program conversion device and program conversion system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To support efficient tuning of a source program. <P>SOLUTION: A parser 182 generates first intermediate code from a source program 141. A logical guarantee optimizer 184 generates second intermediate code by way of performing optimization processing corresponding to a target processor for the first intermediate code. An optimality attainment level analyzer 186 analyzes performance of the second intermediate code and outputs optimality attainment level information 142 indicating results of the performance analysis. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a program conversion apparatus and a program conversion system for converting a source program into a code for a target processor.

  In recent years, high performance in media processing has been demanded. The media processing is, for example, image and audio encoding processing and image and audio decoding processing. Until now, if only a single conversion process was performed, the product requirement was satisfied, but due to the high performance of the product, the congestion processing of the encoding process and the decoding process has been required, so the higher performance Media processing is required. For this reason, optimization processing by a compiler has been implemented, and the optimization processing has been improved so far.

  However, as the demand for improving the performance of media processing increases, it has become necessary to write code that improves the efficiency of optimization processing in the compiler. A program developer (hereinafter referred to as a programmer) has used optimization processing of the compiler by describing optimization assistance information by the #pragma instruction to the compiler and tuning the program.

  However, the programmer does not know how much performance improvement can be achieved by applying what kind of tuning to which part of the source program. Therefore, the tuning is repeated to confirm how much the performance has improved by correcting the source program. It is necessary to carry out and spend a great deal of man-hours.

  Patent Document 1 discloses a technique (hereinafter referred to as Conventional Technology A) that informs a programmer where to perform tuning in order to solve the above problem. Specifically, Patent Document 1 discloses an optimizing compiler that outputs contents obtained by optimizing a source program as a compile list file.

  Non-Patent Document 1 discloses an interactive optimization compiler that prompts input of auxiliary information for further optimizing an input program.

Japanese Patent Laid-Open No. 5-108372

Hans Zima, Barbara Chapman, Yoichi Muraoka, “Supercompilers for Parallel and Vector Computers”, 1st edition, Ohmsha, April 25, 1995

  In the prior art A, the contents of the optimization process performed on the source program are output. The program repeats tuning of the source program based on the contents of the optimization process.

  However, the programmer must confirm the optimality of the source program by repeatedly performing tuning on the source program that may already be the best until the tuning effect converges. That is, the programmer needs to spend a great amount of man-hours for tuning, and the efficiency of tuning the source program is poor.

  The present invention has been made to solve the above-described problems, and an object thereof is to support efficient tuning of a source program.

  In order to solve the above-described problem, a program conversion device according to an aspect of the present invention converts a source program described in a high-level language into a code for a target processor. The program conversion device generates a second intermediate code by performing an intermediate code generation unit that generates a first intermediate code from a source program and an optimization process corresponding to the target processor for the first intermediate code. An optimization unit, and an analysis unit that analyzes the performance of the second intermediate code and outputs optimality achievement information indicating the result of the performance analysis.

  That is, the intermediate code generation unit generates the first intermediate code from the source program. The optimization unit generates a second intermediate code by performing an optimization process corresponding to the target processor on the first intermediate code. The analysis unit analyzes the performance of the second intermediate code and outputs optimality achievement information indicating the result of the performance analysis.

  Therefore, the programmer can grasp the result of the performance analysis of the second intermediate code corresponding to the source program by referring to the optimality achievement degree information. As a result, the programmer can grasp the effect of tuning on the source program corresponding to the second intermediate code. That is, by outputting the optimality reachability information, it is possible to assist the programmer in efficiently tuning the source program.

  Further, the program conversion apparatus further performs a specific condition relaxation optimization process, which is an optimization process in which a specific condition is relaxed, for the first intermediate code, thereby generating a third intermediate code. A condition relaxation optimization unit is provided, and the analysis unit further analyzes the performance of the third intermediate code and outputs optimality reachability information indicating the analysis results of the performance of the second intermediate code and the third intermediate code. It is preferable to do.

Thereby, the analysis result of the performance of the second and third intermediate codes can be grasped.
Further, it is preferable that the specific condition relaxation optimizing unit further outputs information on a condition in which the specific condition is relaxed.

  Moreover, it is preferable that the program conversion apparatus further includes a reception unit that receives an instruction, and the specific condition relaxation optimization unit performs a specific condition relaxation optimization process based on a condition indicated by the instruction received by the reception unit.

Moreover, it is preferable that the instruction received by the reception unit is an instruction by a command line.
Moreover, it is preferable that the instruction received by the receiving unit is an instruction included in the source program.

  In addition, the program conversion apparatus further performs a logic unguaranteed optimization process, which is an optimization process that does not guarantee the validity of the logic, on the first intermediate code, thereby generating a fourth logic code that does not generate a fourth intermediate code. A guarantee optimization unit is provided, and the analysis unit further analyzes the performance of the fourth intermediate code, and outputs optimum reachability information indicating the analysis results of the performance of the second intermediate code and the fourth intermediate code. It is preferable.

Thereby, the analysis result of the performance of the second and fourth intermediate codes can be grasped.
Further, it is preferable that the logic non-guaranteed optimization unit further outputs information on conditions for which the logical validity is not guaranteed.

  The program conversion apparatus further includes a receiving unit that receives an instruction, and the logical unguaranteed optimization unit performs a logical unguaranteed optimization process based on a condition that does not require a logical guarantee indicated by the instruction received by the receiving unit. It is preferable to carry out.

Moreover, it is preferable that the instruction received by the reception unit is an instruction by a command line.
Moreover, it is preferable that the instruction received by the receiving unit is an instruction included in the source program.

  Further, it is preferable that the optimality reachability information indicates at least the optimal degree of the second intermediate code for the target processor.

  A program conversion system according to another aspect of the present invention is a system for converting a source program described in a high-level language into a machine language code for a target processor. The program conversion system includes an intermediate code generation unit that generates a first intermediate code from a program and an optimization process that generates a second intermediate code by performing an optimization process on the first intermediate code according to a target processor. An analysis unit that outputs performance reachability information indicating the result of the performance analysis by analyzing the performance of the second intermediate code, and a target processor using a file based on the second intermediate code A machine language code generation unit that generates machine language code that operates on the machine.

  Note that the present invention is not only realized as a program conversion apparatus including such characteristic means, but also realized as a program conversion method in which each unit performing characteristic processing included in the program conversion apparatus is a step, It can also be realized as a program for causing a computer to function as characteristic means included in the program conversion apparatus. Needless to say, such a program can be distributed via a recording medium such as a CD-ROM (Compact Disc-Read Only Memory) or a communication network such as the Internet.

  According to the present invention, efficient tuning of a source program can be supported.

It is a figure which shows the external appearance of a computer. It is the block diagram which showed the hardware constitutions in a computer. It is a figure which shows the structure of the compiler system in 1st Embodiment. It is a figure which shows the structure of the compiler in 1st Embodiment. It is a flowchart of the process which a compiler performs. It is a flowchart of optimality achievement analysis processing. It is a figure which shows an example of a source program. It is a figure which shows the optimality achievement level information as an example in 1st Embodiment. It is a figure which shows the structure of the compiler system in 2nd Embodiment. It is a figure which shows the structure of the compiler in 2nd Embodiment. It is a flowchart of the process which a compiler performs. It is a flowchart of the optimality achievement analysis process A. It is a figure which shows the optimality achievement level information as an example in 2nd Embodiment. It is a figure which shows the structure of the compiler in the modification 1 of 2nd Embodiment. It is a figure which shows the structure of the compiler system in the modification 2 of 2nd Embodiment. It is a figure which shows the structure of the compiler in the modification 2 of 2nd Embodiment. It is a figure which shows the structure of the compiler system in 3rd Embodiment. It is a figure which shows the structure of the compiler in 3rd Embodiment. It is a flowchart of the process which a compiler performs. It is a flowchart of optimality achievement analysis processing C. It is a figure which shows the optimality achievement level information as an example in 3rd Embodiment. It is a figure which shows the structure of the compiler in the modification 1 of 3rd Embodiment. It is a figure which shows the structure of the compiler system in the modification 2 of 3rd Embodiment. It is a figure which shows the structure of the compiler in the modification 2 of 3rd Embodiment.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. In the following description, the same parts are denoted by the same reference numerals. Their names and functions are also the same. Therefore, detailed description thereof will not be repeated.

<First Embodiment>
Hereinafter, the compiler system in the first embodiment will be described.

  The compiler system in the first embodiment is realized by executing a program in the computer 500 shown in FIG.

Next, the computer 500 will be described in detail.
FIG. 2 is a block diagram showing a hardware configuration in the computer 500. Note that FIG. 2 also shows a recording medium 50 for explanation. On the recording medium 50, a program 51 to be described later is recorded. That is, the program 51 is recorded on a medium or the like and distributed as a program product. The recording medium 50 is also distributed as a program product.

  As shown in FIG. 2, the computer 500 includes a control unit 510, a RAM (Random Access Memory) 520, a storage unit 522, a storage medium access unit 530, a display unit 540, a keyboard 551, a mouse 552, and the like. And a communication unit 560.

  Control unit 510, RAM 520, storage unit 522, storage medium access unit 530, display unit 540, keyboard 551, mouse 552 and communication unit 560 are connected to data bus 502.

  Control unit 510 is a CPU (Central Processing Unit). Control unit 510 is not limited to a CPU, and may be another circuit having an arithmetic function.

  The RAM 520 is a volatile memory. The RAM 520 is accessed by the control unit 510. The RAM 520 functions as a work memory that temporarily stores data.

  The storage unit 522 is a nonvolatile memory. Storage unit 522 is, for example, a hard disk drive. The storage unit 522 is not limited to a hard disk drive, and may be another memory (for example, a flash memory) as long as it is a nonvolatile memory. The storage unit 522 is accessed by the control unit 510. The storage unit 522 stores a program 51 and other various data.

  Control unit 510 executes program 51 stored in storage unit 522, and performs various types of processing, arithmetic processing, and the like for each unit in computer 500 based on program 51.

  The storage medium access unit 530 has a function of reading the program 51 from the recording medium 50 in which the program 51 is stored according to an instruction from the control unit 510. The program 51 stored in the recording medium 50 is read out by the storage medium access unit 530 and stored in the storage unit 522 by an installation process performed by the control unit 510. This installation processing program is stored in the storage unit 522 in advance. Installation processing is performed by control unit 510 based on an installation processing program.

  The recording medium 50 is a CD-ROM (Compact Disc-Read Only Memory). The recording medium 50 is not limited to a CD-ROM, and may be another medium capable of recording data in a nonvolatile manner (for example, an SD (Secure Digital) memory card).

  The display unit 540 has a function of displaying characters, images, and the like. The display unit 540 is provided with a display surface for displaying characters, images, and the like. The display unit 540 is a device that uses an LCD panel (Liquid Crystal Display Panel). Note that the display unit 540 may be a device using a panel of a display method other than the above.

  The user gives an instruction to the computer 500 by operating the keyboard 551 or the mouse 552. An input instruction from the keyboard 551 or the mouse 552 is transmitted to the control unit 510. Control unit 510 performs predetermined processing based on an input instruction from keyboard 551 or mouse 552. That is, the keyboard 551 and the mouse 552 are interfaces for the user to operate the computer 500.

  The communication unit 560 has a function of performing data communication with a device connected to a network using a wired technology or a wireless technology. The wired technology is, for example, technology based on Ethernet (registered trademark). The wired technology is not limited to a technology based on Ethernet (registered trademark), and may be another wired technology.

(System configuration (basic))
FIG. 3 is a diagram illustrating a configuration of the compiler system 148 according to the first embodiment. The compiler system 148 is realized by the program 51 being executed by the control unit 510. That is, the program 51 includes a compiler system 148.

  The compiler system 148 is a software system that converts a source program 141 described in a high-level language such as C language into an execution program 145 described in machine language code. Specifically, the compiler system 148 is a software system that converts the source program 141 into an execution program 145 that can be executed by the target processor. Here, the target processor is a CPU that is a target for executing the execution program 145. The CPU is a CPU used in a computer.

  The target processor has multiple types of hardware resources. The plural types of hardware resources are, for example, an execution unit, a cache memory, an instruction decode unit, and the like. The execution unit includes an arithmetic unit (ALU), a register, and the like.

  The compiler system 148 includes a compiler 149, an assembler 150, and a linker 151.

  The compiler 149 is a program that converts the source program 141 into an assembler file 143 for the target processor. The assembler file 143 is a file described in an assembler language.

  The compiler 149 performs optimization processing when the source program 141 is converted into the assembler file 143, and outputs the assembler file 143 and the optimality achievement degree information 142. The optimality achievement degree information 142 is information indicating the result of analyzing the optimality for the source program 141.

  The assembler 150 is a program that converts an assembler file 143 described in an assembler language into an object file 144 described in a machine language code.

  The linker 151 is a program that combines a plurality of object files 144 to generate an execution program 145. The execution program 145 is a program that operates on the target processor. That is, the assembler 150 and the linker 151 constitute a machine language code generation unit that uses the assembler file 143 to generate an execution program 145 described in machine language code.

(Compiler configuration (basic))
FIG. 4 is a diagram illustrating a configuration of the compiler 149 according to the first embodiment.

  The compiler 149 includes a syntax analysis unit 182, a logic guarantee optimization unit 184, an optimality achievement level analysis unit 186, and a code output unit 188. Each part in the compiler 149 is realized as a program module.

  The syntax analysis unit 182 generates an intermediate code (hereinafter referred to as a first intermediate code) by performing a syntax analysis process on the source program 141, and outputs the first intermediate code. That is, the syntax analysis unit 182 is an intermediate code generation unit that generates a first intermediate code from the source program 141.

  Here, it is assumed that the optimization process described below is an optimization process performed by a general optimization compiler. The optimization process includes, for example, a process for reducing the number of loops, a process for reducing the number of instruction executions, a process for reducing the code size, and a process for reducing the number of branches. Since the optimization process is the same as the process performed by a general compiler, detailed description will not be repeated.

  The logic guarantee optimization unit 184 performs an optimization process that guarantees the validity of the logic for the first intermediate code. The optimization process that guarantees the correctness of logic is, for example, a process in which the logic (algorithm) of the intermediate code obtained by performing the optimization process is consistent. That is, the logic guarantee optimization unit 184 performs an optimization process on the first intermediate code within a range in which the logic validity can be guaranteed.

  Hereinafter, the optimization process performed by the logic assurance optimization unit 184 is referred to as a logic assurance optimization process.

  Specifically, the logic assurance optimization unit 184 performs optimization processing on the first intermediate code by performing optimization processing (logic assurance optimization processing) according to the specifications of the target processor. Output an intermediate code (hereinafter referred to as a second intermediate code). The second intermediate code is an intermediate code obtained by performing optimization processing on the first intermediate code. That is, the logic assurance optimization unit 184 generates the second intermediate code by performing optimization processing corresponding to the target processor on the first intermediate code.

In this case, the second intermediate code is a code having no contradiction in logic (algorithm).
One of the tuning methods generally performed by programmers is a general memory dependence mitigation method using a restrict modifier defined in the C99 language. The C99 language is a C language based on the standard of “ISO / IEC 9899: 1999-Programming Language C”. Since the restrict qualifier and apparent memory dependence are common and well known, a detailed description thereof will not be given here.

  In the present embodiment, for example, paying attention to the apparent memory dependence, the logic assurance optimization unit 184 performs a logic assurance optimization process in consideration of the apparent memory dependence on the first intermediate code. A second intermediate code is obtained.

  Based on the second intermediate code output from the logic assurance optimization unit 184, the optimality reachability analysis unit 186 calculates optimality information as the reachability of the optimality of the second intermediate code. The optimality information is a ratio of how efficiently the second intermediate code can use the hardware resources of the target processor. The optimality information includes, for example, a register resource usage rate, an arithmetic unit resource usage rate, a pipeline occupancy rate, a bus width occupancy rate, an IPC (Instruction par Cycle), and a stall rate.

  The optimality achievement level analysis unit 186, for example, compares the second intermediate code with the architecture specification of the target processor, and outputs the optimality achievement level information 142 indicating the calculated optimality information.

  That is, the optimality reachability analysis unit 186 analyzes (analyzes) the optimality reachability (optimum degree) of the second intermediate code, and the optimality reachability information indicating the result (optimum degree) of the analysis (analysis) 142 is output. That is, the optimality achievement level analysis unit 186 analyzes the performance of the second intermediate code and outputs the optimality achievement level information 142 indicating the result of the performance analysis. In this case, the optimality achievement information 142 indicates the optimum degree of the second intermediate code.

  The code output unit 188 converts the second intermediate code optimized by guaranteeing the logic by the logic guarantee optimization unit 184 into an assembler language, and outputs an assembler file 143. That is, the assembler file 143 is a file based on the second intermediate code.

(Flow of compiler processing (basic))
Next, the flow of processing executed by the compiler 149 will be described.

FIG. 5 is a flowchart of processing executed by the compiler 149.
The syntax analysis unit 182 performs syntax analysis of the source program 141 and generates a first intermediate code (S1). The logic guarantee optimization unit 184 generates the second intermediate code by performing the above-described logic guarantee optimization process on the first intermediate code (S2).

  The optimality reachability analysis unit 186 analyzes (analyzes) the reachability of the optimality of the second intermediate code, and outputs optimality reachability information 142 indicating the result of the analysis (analysis) (S3).

  The code output unit 188 converts the second intermediate code into an assembler language and outputs it as an assembler file 143 (S4).

(Detailed flow of optimality achievement analysis processing (basic))
Next, the optimality achievement analysis process in step S3 of FIG. 5 will be described in detail.

FIG. 6 is a flowchart of optimality reachability analysis processing.
The optimality reach analysis unit 186 divides the second intermediate code for each function (procedure) and analyzes the second intermediate code (S31).

  Next, the optimality achievement level analysis unit 186 divides the second intermediate code divided for each function in step S31 for each basic block, and analyzes each divided second intermediate code ( S32). Here, the basic block is a block without a branch instruction.

  Next, the optimality achievement level analysis unit 186 generates DAG (Directed acyclic graph) information corresponding to each second intermediate code divided for each basic block in step S32 (S33). The DAG information is information indicating an effective graph having no cycle.

  Next, the optimality achievement level analysis unit 186 registers the generated DAG information and the result of comparison with the architecture specification of the target processor in the performance analysis information database 201D. Specifically, the optimality attainment analysis unit 186 registers the number identifying the basic block and the comparison result in the performance analysis information database 201D with the function symbol name as the main key (S34).

  For example, assume that the architecture specification of the target processor indicates that three instructions can be issued simultaneously. In this case, it is assumed that the IPC (Instruction Par Cycle) of the divided second intermediate code is analyzed from the DAG information as 2.5. The IPC is the number of instructions that can be executed by the target processor in one cycle.

  In this case, the optimality achievement is 2.5 / 3 = 83%. That is, the optimality achievement level of 83% is registered in the performance analysis information database 201D by the process of step S34.

  Next, in step S35, the optimality achievement degree analysis unit 186 shapes the basic block number and the comparison result for each function name of the primary key from the performance analysis information database 201D, and shows the information after the shaping. Sexual reach information 142 is output. In this case, the control unit 510 performs a process for causing the display unit 540 to display the optimality achievement degree information 142, for example. Then, the optimality reachability analysis process ends.

  Here, it is assumed that the source program 141 is a program shown in FIG. 7 as an example. In this case, the optimality achievement information 142 output by performing the processing of FIG. 5 and the optimality achievement analysis processing of FIG. 6 is information shown in FIG. 8 as an example.

  FIG. 8 is a diagram showing the optimality achievement degree information 142 as an example in the first embodiment.

  In FIG. 8, “BasicBlockNum” is a basic block number. “IPC (analysis result)” indicates the IPC of the divided second intermediate code corresponding to the basic block number, obtained by the optimality reachability analysis process. “IPC (specification)” is an IPC indicated as an architecture specification of the target processor.

  The “optimum achievement level” in FIG. 8 is a value calculated by the equation (IPC (analysis result) / IPC (specification)). The “optimum achievement level” is calculated by the optimality level analysis unit 186 in the process of step S34. In this case, the “optimum achievement level” is a comparison result in the process of step S34.

  The closer the optimality achievement level corresponding to the basic block is to a value close to 100 (%), the more the source code of the part corresponding to the basic block described in the source program 141, the hardware resources of the target processor, It can be used more efficiently. In other words, the optimum degree of achievement indicates the optimum degree of the algorithm of the source code of the part corresponding to the basic block described in the source program 141.

  When the optimality achievement degree corresponding to the basic block is 100 (%), the source code of the part corresponding to the basic block described in the source program 141 uses the hardware resources of the target processor most efficiently. It will be usable.

  For example, in FIG. 8, the optimal reachability of the divided second intermediate code corresponding to the basic block number “2” is the highest. That is, the optimality of the algorithm of the source code of the part corresponding to the basic block number “2” described in the source program 141 is the best.

  The information (optimum reachability information 142) shown in FIG. 8 is displayed on the display unit 540, so that the programmer grasps the optimum degree of the algorithm of the source code described in the source program 141 being created. can do.

  As described above, in this embodiment, when the source program 141 is compiled, the optimality achievement level as the optimality of the algorithm of the source program 141 is displayed on the display unit 540.

  Therefore, the programmer can grasp the optimum degree of the algorithm of the source code described in the source program 141 being created. As a result, the programmer can tune the source program 141 without wasting the number of development steps.

  In other words, according to the present embodiment, it is possible to easily specify a portion in the source program 141 where an improvement effect can be expected. Therefore, the programmer can efficiently tune the program without spending a lot of time in tuning the program that does not improve performance no matter how much it is modified.

  That is, the information (optimum reachability information 142) shown in FIG. 8 is displayed (output) on the display unit 540, so that the programmer can be assisted in efficient tuning of the source program.

<Second Embodiment>
Hereinafter, a compiler system according to the second embodiment will be described.

  The compiler system in the second embodiment is realized by executing a program in the computer 500 shown in FIG.

(System configuration (relaxation of specific conditions))
FIG. 9 is a diagram illustrating a configuration of a compiler system 148A according to the second embodiment. The compiler system 148A is realized by the program 51 being executed by the control unit 510. That is, the program 51 includes a compiler system 148A.

  9, compiler system 148A differs from compiler system 148 in FIG. 3 in that it includes compiler 149A instead of compiler 149. Since other configurations are the same as those of the compiler system 148, detailed description will not be repeated.

(Compiler configuration (relaxation of specific conditions))
FIG. 10 is a diagram illustrating a configuration of the compiler 149A according to the second embodiment.

  Referring to FIG. 10, compiler 149 </ b> A further includes a specific condition relaxation optimization unit 183 as compared with compiler 149 of FIG. 4, and an optimality reachability analysis unit instead of optimality reachability analysis unit 186. The difference is that it includes 186A. Since other configurations are the same as those of the compiler 149, detailed description will not be repeated. Each unit in the compiler 149A is realized as a program module.

  The syntax analysis unit 182 transmits the above-described first intermediate code to the logic guarantee optimization unit 184 and the specific condition relaxation optimization unit 183.

  The specific condition relaxation optimization unit 183 performs an optimization process (hereinafter referred to as a specific condition relaxation optimization process) in which a specific condition is relaxed for the first intermediate code received from the syntax analysis unit 182. That is, the specific condition relaxation optimization process is an optimization process based on a condition in which the specific condition is relaxed (hereinafter referred to as a relaxation specific condition). The specific condition is one optimization condition among a plurality of types of optimization conditions implemented in a general compiler.

  Specific conditions include, for example, the above-described restrictions on apparent memory access (apparent memory dependence), alignment of pointer registers, and the like, the number of instructions (code size), and operational unit resources used. In the following, apparent memory dependence is simply referred to as apparent dependence.

  The specific condition is a condition that, for example, in the constraint on the apparent dependency, it is assumed that the mutual memory access by the plurality of pointer variables has an apparent dependency. In this case, the relaxation specifying condition is, for example, a condition that it is assumed that no apparent dependence occurs with respect to the pointer variable of the dummy argument. In this case, the optimization process (specific condition relaxation optimization process) in which the specific condition is relaxed is a process in which the apparent dependency of the code targeted for the optimization process does not occur with respect to the pointer variable of the dummy argument, for example. Including.

  The specific condition is, for example, a condition that a memory access instruction corresponding to the alignment must be generated for a memory access using a pointer variable in a constraint related to alignment. In this case, the relaxation specifying condition is, for example, a condition that the alignment is 8-byte alignment with respect to the pointer variable of the dummy argument. In this case, the optimization process (specific condition relaxation optimization process) in which the specific condition is relaxed performs the alignment of the memory access included in the code to be optimized, for example, 8-byte alignment with respect to the pointer variable of the dummy argument. Including processing.

  The specific condition is, for example, a condition that the number of instructions in the code to be optimized is 50% or less. In this case, the relaxation specifying condition is, for example, a condition that the number of instructions in the code to be optimized is, for example, 60% or less. In this case, the optimization process in which the specific condition is relaxed (specific condition relaxation optimization process) includes a process in which the number of instructions in the code to be optimized is, for example, 60% or less.

  The specific condition is, for example, a condition that the number of used computing unit resources of instructions in the code to be optimized is 50% or less. In this case, the relaxation specifying condition is, for example, a condition that the number of used arithmetic unit resources of instructions in the code to be optimized is, for example, 60% or less. In this case, the optimization process in which the specific condition is relaxed (specific condition relaxation optimization process) includes a process in which, for example, the number of used arithmetic unit resources in the code targeted for the optimization process is reduced to 60% or less. .

The relaxation specific condition can be applied to various optimization conditions implemented in the compiler.
The specific condition relaxation optimizing unit 183 performs the specific condition relaxation optimization process on the first intermediate code, so that the intermediate code subjected to the specific condition relaxation optimization process (hereinafter referred to as a third intermediate code). Is output. That is, the specific condition relaxation optimizing unit 183 generates the third intermediate code by performing the specific condition relaxation optimization process on the first intermediate code.

  The specific condition relaxation optimization unit 183 transmits the third intermediate code to the optimality achievement degree analysis unit 186A.

  In addition to the processing described in the first embodiment, the logic guarantee optimization unit 184 transmits the second intermediate code to the optimality reachability analysis unit 186A.

  Optimality reach analysis unit 186A receives the second intermediate code and the third intermediate code. Optimality reach analysis unit 186A analyzes (analyzes) the performance of the second intermediate code and the third intermediate code so that the performance of the second intermediate code and the third intermediate code can be compared. And the optimum reachability information 142 indicating the analysis results of the performance of the second intermediate code and the third intermediate code is output.

  In this case, the optimality achievement degree information 142 indicates an analysis result so that the performance of the second intermediate code can be compared with the performance of the third intermediate code.

(Flow of compiler processing (relaxation of specific conditions))
Next, the flow of processing executed by the compiler 149A will be described.

  FIG. 11 is a flowchart of processing executed by the compiler 149A. In FIG. 11, the process with the same step number as the step number of FIG. 5 is performed in the same way as the process described in the first embodiment, and therefore detailed description will not be repeated.

  The syntax analysis unit 182 performs syntax analysis of the source program 141 and generates a first intermediate code (S1). The syntax analysis unit 182 transmits the first intermediate code to the logic guarantee optimization unit 184 and the specific condition relaxation optimization unit 183.

  Similarly to the first embodiment, the logic guarantee optimization unit 184 generates the second intermediate code by performing the above-described logic guarantee optimization process on the first intermediate code. Then, the logic guarantee optimization unit 184 transmits the second intermediate code to the optimality reachability analysis unit 186A and the code output unit 188 (S2A).

  The specific condition relaxation optimization unit 183 generates the third intermediate code by performing the above-described specific condition relaxation optimization process on the first intermediate code, and analyzes the third intermediate code with the optimality reachability analysis. Transmit to the unit 186A (S6).

  Optimality reachability analysis unit 186A analyzes (analyzes) the reachability of optimality of the second intermediate code and the third intermediate code, and outputs optimality reachability information 142 indicating the result of the analysis (analysis). (S3A optimality achievement analysis process A). That is, the optimality reachability analysis unit 186A outputs the optimality reachability information 142 indicating the analysis results of the performance of the second intermediate code and the third intermediate code.

(Detailed flow of optimality achievement analysis process A (relaxation of specific conditions))
Next, the optimality achievement analysis process A in step S3A of FIG. 11 will be described in detail.

  FIG. 12 is a flowchart of the optimality achievement level analysis process A. In FIG. 12, the process with the same step number as the step number of FIG. 6 is performed in the same way as the process described in the first embodiment, and therefore detailed description will not be repeated.

  The optimality reachability analysis unit 186A analyzes the second intermediate code by dividing the second intermediate code for each function (procedure) (S31).

  Next, the optimality achievement level analysis unit 186A divides the second intermediate code divided for each function in step S31 for each basic block, and analyzes each divided second intermediate code ( S32).

  Next, the optimality achievement degree analysis unit 186A generates DAG information corresponding to each second intermediate code divided for each basic block (S33).

  Next, the optimality achievement level analysis unit 186A determines the number of cycles as cycle information (hereinafter referred to as the number of logic guarantee cycles) by analyzing the height of the DAG indicated by the generated DAG information (S36). The number of logic assurance cycles is the number of cycles necessary for the target processor to execute the second intermediate code corresponding to the DAG information to be processed.

  Further, the optimality achievement level analysis unit 186A registers the number identifying the basic block with the function symbol name as the primary key in association with the number of logical guarantee cycles as the cycle information in the performance analysis information database 211D (S36). ).

  Similar to steps S31 to S36 in FIG. 12, the optimality achievement degree analysis unit 186A performs the following processing.

  First, the optimality achievement level analysis unit 186A analyzes the third intermediate code by dividing the third intermediate code for each function (procedure) (S61).

  Next, the optimality achievement level analysis unit 186A divides the second intermediate code divided for each function in step S61 for each basic block, and analyzes each divided third intermediate code ( S62).

  Next, the optimality achievement degree analysis unit 186A generates DAG information corresponding to each third intermediate code divided for each basic block (S63).

  Next, the optimality achievement degree analysis unit 186A obtains the number of cycles (hereinafter referred to as the number of condition relaxation cycles) as cycle information by analyzing the height of the DAG indicated by the generated DAG information (S64).

  Further, the optimality achievement level analysis unit 186A registers the number identifying the basic block with the function symbol name as the main key and the condition relaxation cycle number as the cycle information in the performance analysis information database 212D (S64). ).

  Next, in step S35A, the optimality achievement degree analysis unit 186A shapes the basic block number and cycle information for each function name of the primary key from each of the performance analysis information database 211D and the performance analysis information database 212D. The optimality achievement degree information 142 indicating the information after being output is output. In this case, the control unit 510 performs a process for causing the display unit 540 to display the optimality achievement degree information 142, for example. And this optimality achievement analysis process A is complete | finished.

  Here, it is assumed that the source program 141 is a program shown in FIG. 7 as an example. In this case, the optimality achievement information 142 output by performing the process of FIG. 11 and the optimality achievement analysis process A of FIG. 12 is information shown in FIG. 13 as an example.

  FIG. 13 is a diagram illustrating optimality achievement degree information 142 as an example in the second embodiment.

  In FIG. 13, “BasicBlockNum” is a basic block number. The “number of logic guarantee cycles” is the number of logic guarantee cycles as cycle information corresponding to the divided second intermediate code obtained by the optimality reachability analysis process A. “The number of condition relaxation cycles” is the number of condition relaxation cycles as cycle information corresponding to the divided third intermediate code obtained by the optimum reachability analysis process A.

  The “optimum achievement degree” in FIG. 13 is a value calculated by the equation (number of condition relaxation cycles / number of logic guarantee cycles). The “optimum achievement level” is calculated by the optimality level analysis unit 186A in the process of step S35A. The optimality achievement level analysis unit 186A sets the optimality achievement level to 100 when the number of condition relaxation cycles is larger than the number of logical guarantee cycles.

  The “optimum achievement degree” in FIG. 13 is the same as the “optimum achievement degree” described in FIG. 8, and therefore, detailed description thereof will not be repeated. That is, the closer the optimality achievement level corresponding to the basic block is to 100 (%), the more the source code of the part corresponding to the basic block described in the source program 141 is the hardware resource of the target processor. Can be used more efficiently. In other words, the optimum degree of achievement indicates the optimum degree of the algorithm of the source code of the part corresponding to the basic block described in the source program 141.

  For example, in FIG. 13, the optimal reachability of the divided second intermediate code corresponding to the basic block number “1” is the highest. That is, the optimality of the algorithm of the source code corresponding to the basic block number “1” described in the source program 141 is the best.

  The information shown in FIG. 13 (optimum achievement level information 142) is displayed on the display unit 540, whereby the programmer grasps the optimum degree of the algorithm of the source code described in the source program 141 being created. can do.

  As described above, also in this embodiment, the same effect as that of the first embodiment can be obtained. That is, the programmer can grasp the optimum degree of the algorithm of the source code described in the source program 141 being created. As a result, the programmer can tune the source program 141 without wasting the number of development steps.

  That is, the information (optimum reachability information 142) shown in FIG. 13 is displayed (output) on the display unit 540, so that the programmer can be assisted in efficient tuning of the source program.

<Modification 1 of the second embodiment>
Next, a configuration for outputting information on conditions (hereinafter referred to as relaxation specific conditions) in which specific conditions are relaxed will be described.

  The compiler system in the first modification of the second embodiment is the compiler system 148A in FIG.

(Output of relaxation specific conditions)
FIG. 14 is a diagram illustrating a configuration of the compiler 149A according to the first modification of the second embodiment. Since compiler 149A shown in FIG. 14 has the same configuration as compiler 149A of FIG. 10, detailed description thereof will not be repeated.

  The specific condition relaxation optimizing unit 183 in FIG. 14 outputs information on the relaxed specific condition with the specific condition relaxed, in addition to the processing described in the second embodiment. Information on the relaxation specifying condition is registered in the optimality achievement degree information 142.

<Modification 2 of the second embodiment>
Next, a configuration for receiving the relaxation specific condition from the outside will be described.

(System configuration)
FIG. 15 is a diagram illustrating a configuration of a compiler system 148B according to the second modification of the second embodiment. The compiler system 148B is realized by the program 51 being executed by the control unit 510. That is, the program 51 includes a compiler system 148B.

  Referring to FIG. 15, compiler system 148 </ b> B is different from compiler system 148 in FIG. 3 in that it includes compiler 149 </ b> B instead of compiler 149. Since other configurations are the same as those of the compiler system 148, detailed description will not be repeated.

(Enter relaxation specific conditions)
FIG. 16 is a diagram illustrating a configuration of the compiler 149B according to the second modification of the second embodiment.

  Referring to FIG. 16, compiler 149 </ b> B is different from compiler 149 </ b> A in FIG. 10 in that it further includes a reception unit 189. Since other configurations are similar to those of compiler 149A, detailed description will not be repeated. Each unit in the compiler 149B is realized as a program module.

  The accepting unit 189 accepts an instruction from the outside. Specifically, the reception unit 189 receives the relaxation specifying condition 160 indicated by the received instruction. The accepting unit 189 transmits the accepted relaxation specific condition 160 to the specific condition relaxation optimization unit 183.

  For example, the accepting unit 189 accepts the relaxation specifying condition 160 indicated by the command line instruction. The command line instruction is an instruction as a compiler option. The command line instruction is performed, for example, when the programmer operates the keyboard 551.

  For example, the accepting unit 189 accepts the relaxation specifying condition 160 indicated by the instruction by the #pragma instruction (see FIG. 7) described in the source program 141. In this case, the accepting unit 189 accepts the relaxation specifying condition 160 from the source program 141.

  Note that each part in the compiler 149B performs the same processing as in the second embodiment, and thus detailed description will not be repeated.

  That is, the specific condition relaxation optimizing unit 183 performs the third intermediate code by performing the specific condition relaxation optimization process based on the relaxed specific condition 160 indicated by the instruction received by the receiving unit 189 with respect to the first intermediate code. Generate code.

<Third Embodiment>
Next, a compiler system according to the third embodiment will be described.

  The compiler system in the third embodiment is realized by executing a program in the computer 500 shown in FIG.

(System configuration (logical unguaranteed))
FIG. 17 is a diagram illustrating a configuration of a compiler system 148C according to the third embodiment. The compiler system 148C is realized by the program 51 being executed by the control unit 510. That is, the program 51 includes a compiler system 148C.

  17, compiler system 148C is different from compiler system 148 in FIG. 3 in that a compiler 149C is included instead of compiler 149. Since other configurations are the same as those of the compiler system 148, detailed description will not be repeated.

(Compiler configuration (logic not guaranteed))
FIG. 18 is a diagram illustrating a configuration of the compiler 149C according to the third embodiment.

  Referring to FIG. 18, compiler 149 </ b> C further includes a logic unguaranteed optimization unit 185 as compared with compiler 149 of FIG. 4, and an optimality reachability analysis unit instead of optimality reachability analysis unit 186. The difference is that it includes 186C. Since other configurations are the same as those of the compiler 149, detailed description will not be repeated. Each unit in the compiler 149C is realized as a program module.

  The syntax analysis unit 182 transmits the above-described first intermediate code to the logic guarantee optimization unit 184 and the logic unguarantement optimization unit 185.

  The logic unguaranteed optimization unit 185 performs an optimization process (hereinafter referred to as a logic unguaranteed optimization process) that does not guarantee the validity of the logic of the specific condition for the first intermediate code received from the syntax analysis unit 182. Do. Hereinafter, a specific condition for which logic is not guaranteed by the logic unguaranteed optimization process is referred to as a logic unguaranteed condition.

  As will be described later, the logical unguaranteed condition may be designated from the outside. In this case, the specified logic unguaranteed condition is a condition that does not require a logic guarantee. That is, the logical unguaranteed optimization process is an optimization process based on the logical unguaranteed condition. In this case, the logical unguaranteed optimization process based on the logical unguaranteed condition is a process that does not guarantee the specified logical unguaranteed condition.

  The logic unguaranteed optimization process is, for example, a process that may cause a contradiction in the logic (algorithm) of the intermediate code obtained by performing the logic unguaranteed optimization process. That is, the logic unguaranteed optimization process is an optimization process in which the restriction of the logic guarantee is relaxed for the intermediate code.

  Here, as an example, the specific condition (logical unguaranteed condition) is, for example, a condition that there is no contradiction in memory allocation. In this case, the logic non-guaranteed optimization process is performed, so that the condition that there is no contradiction in memory allocation cannot be guaranteed. In other words, the logic unguaranteed optimization process may cause inconsistency in memory allocation.

The logic unguaranteed condition can be applied to various optimization conditions implemented in the compiler.
The logic unguaranteed optimization process is, for example, an optimization process that ignores the apparent memory dependence described above. In this case, the logical unguaranteed condition is a condition that guarantees an apparent memory dependence.

  The logic unguaranteed optimization unit 185 performs the logic unguaranteed optimization process on the first intermediate code, thereby performing the logic unguaranteed optimization process (hereinafter referred to as the fourth intermediate code). Is output. That is, the logic unguaranteed optimization unit 185 generates the fourth intermediate code by performing the logic unguaranteed optimization process on the first intermediate code.

  The fourth intermediate code is an intermediate code whose logic validity is not guaranteed. That is, the fourth intermediate code is an intermediate code that may have a contradiction in logic (algorithm).

  The logic unguaranteed optimization unit 185 transmits the fourth intermediate code to the optimality reachability analysis unit 186C.

  In addition to the processing described in the first embodiment, the logic guarantee optimization unit 184 transmits the second intermediate code to the optimality reachability analysis unit 186C.

  Optimality reach analysis unit 186C receives the second intermediate code and the fourth intermediate code. The optimality reachability analysis unit 186C analyzes (analyzes) the performance of the second intermediate code and the fourth intermediate code so that the performance of the second intermediate code and the fourth intermediate code can be compared. And the optimum reachability information 142 indicating the analysis results of the performance of the second intermediate code and the fourth intermediate code is output.

  In this case, the optimality achievement degree information 142 indicates the analysis result so that the performance of the second intermediate code can be compared with the performance of the fourth intermediate code.

(Flow of compiler processing (logic not guaranteed))
Next, the flow of processing executed by the compiler 149C will be described.

  FIG. 19 is a flowchart of processing executed by the compiler 149C. In FIG. 19, the process with the same step number as the step number of FIG. 5 is performed in the same way as the process described in the first embodiment, and therefore detailed description will not be repeated.

  The syntax analysis unit 182 performs syntax analysis of the source program 141 and generates a first intermediate code (S1). The syntax analysis unit 182 transmits the first intermediate code to the logical guarantee optimization unit 184 and the logical unguarantement optimization unit 185.

  Similarly to the first embodiment, the logic guarantee optimization unit 184 generates the second intermediate code by performing the above-described logic guarantee optimization process on the first intermediate code. Then, the logic guarantee optimization unit 184 transmits the second intermediate code to the optimality reachability analysis unit 186C and the code output unit 188 (S2C).

  The specific condition relaxation optimizing unit 183 generates the fourth intermediate code by performing the above-described logic unguaranteed optimization processing on the first intermediate code, and analyzes the fourth intermediate code with the optimality reachability analysis. Transmit to the unit 186C (S7).

  Optimality reach analysis unit 186C analyzes (analyzes) the reach of optimality of the second intermediate code and the fourth intermediate code, and outputs optimum reachability information 142 indicating the result of the analysis (analysis). (S3C Optimality Achievement Analysis Process C). That is, the optimality reachability analysis unit 186C outputs the optimality reachability information 142 indicating the analysis results of the performance of the second intermediate code and the fourth intermediate code.

(Detailed flow of optimality achievement analysis process C (logical unguaranteed))
Next, the optimum reachability analysis process C in step S3C of FIG. 19 will be described in detail.

  FIG. 20 is a flowchart of the optimality achievement analysis process C. In FIG. 20, the processing with the same step number as the step number of FIG. 12 is performed in the same manner as the processing described in the second embodiment, and therefore detailed description will not be repeated.

  In steps S31, S32, S33, and S36, since the process described in the second embodiment is performed by the optimality achievement level analysis unit 186C, detailed description will not be repeated. As a result, the optimality attainment analysis unit 186C registers the number identifying the basic block and the number of logical guarantee cycles as the cycle information in the performance analysis information database 211D using the function symbol name as the main key.

  Similarly to steps S31 to S36 in FIG. 20, the optimality achievement degree analysis unit 186C performs the following processing.

  First, the optimality attainment analysis unit 186C analyzes the fourth intermediate code by dividing the fourth intermediate code for each function (procedure) (S71).

  Next, the optimality achievement level analysis unit 186C divides the fourth intermediate code divided for each function in step S71 for each basic block, and analyzes each divided fourth intermediate code ( S72).

  Next, the optimality achievement degree analysis unit 186C generates DAG information corresponding to each fourth intermediate code divided for each basic block (S73).

  Next, the optimality achievement level analysis unit 186C analyzes the height of the DAG indicated by the generated DAG information, thereby obtaining the number of cycles as cycle information (hereinafter referred to as the number of logical unguaranteed cycles) (S74). .

  Further, the optimality reachability analysis unit 186C registers the number identifying the basic block and the number of logical unguaranteed cycles as cycle information in the performance analysis information database 222D using the function symbol name as a main key ( S74).

  Next, in step S35C, the optimality achievement level analysis unit 186C shapes the basic block number and cycle information for each function name of the primary key from each of the performance analysis information database 211D and the performance analysis information database 222D. The optimality achievement degree information 142 indicating the information after being output is output. In this case, the control unit 510 performs a process for causing the display unit 540 to display the optimality achievement degree information 142, for example. Then, the optimality achievement level analysis process C ends.

  Here, it is assumed that the source program 141 is a program shown in FIG. 7 as an example. In this case, the optimality achievement information 142 output by performing the process of FIG. 19 and the optimality achievement analysis process C of FIG. 20 is information shown in FIG. 21 as an example.

  FIG. 21 is a diagram showing the optimality achievement degree information 142 as an example in the third embodiment.

  In FIG. 21, “BasicBlockNum” is a basic block number. The “number of logic guarantee cycles” is the number of logic guarantee cycles as cycle information corresponding to the divided second intermediate code obtained by the optimum reachability analysis process C. The “number of logical unguaranteed cycles” is the number of logically guaranteed cycles as cycle information corresponding to the divided fourth intermediate code obtained by the optimum reachability analysis process C.

  21 is a value calculated by the formula (number of logical unguaranteed cycles / number of logically guaranteed cycles). The “optimum achievement level” is calculated by the optimality level analysis unit 186C in the process of step S35C. The optimality achievement level analysis unit 186C sets the optimality achievement level to 100 when the number of logical unguaranteed cycles is larger than the number of logically guaranteed cycles.

  The “optimum achievement level” in FIG. 21 is the same as the “optimum achievement level” described with reference to FIG. 8, and therefore, detailed description thereof will not be repeated. That is, the closer the optimality achievement degree corresponding to the basic block is to a value close to 100 (%), the more the source code of the part corresponding to the basic block described in the source program 141 is the hardware resource of the target processor. Can be used more efficiently. In other words, the optimum degree of achievement indicates the optimum degree of the algorithm of the source code of the part corresponding to the basic block described in the source program 141.

  The information shown in FIG. 21 (optimum achievement level information 142) is displayed on the display unit 540, whereby the programmer grasps the optimum degree of the algorithm of the source code described in the source program 141 being created. can do.

  As described above, also in this embodiment, the same effect as that of the first embodiment can be obtained. That is, the programmer can grasp the optimum degree of the algorithm of the source code described in the source program 141 being created. As a result, the programmer can tune the source program 141 without wasting the number of development steps.

  That is, the information (optimum reachability information 142) shown in FIG. 21 is displayed (output) on the display unit 540, so that the programmer can be assisted in efficient tuning of the source program.

<Variation 1 of the third embodiment>
Next, a configuration for outputting information on logical unguaranteed conditions will be described.

  The compiler system in the first modification of the third embodiment is a compiler system 148C in FIG.

(Logical unguaranteed condition output)
FIG. 22 is a diagram illustrating a configuration of the compiler 149C according to the first modification of the third embodiment. Since compiler 149C shown in FIG. 22 has the same configuration as compiler 149C of FIG. 18, detailed description will not be repeated.

  The logical unguaranteed optimization unit 185 in FIG. 22 outputs information on the logical unguaranteed condition in addition to the processing described in the third embodiment. Information on the logical unguaranteed condition is registered in the optimality achievement degree information 142.

<Modification 2 of the third embodiment>
Next, a configuration for receiving a logical unguaranteed condition from the outside will be described.

(System configuration)
FIG. 23 is a diagram illustrating a configuration of a compiler system 148D according to the second modification of the third embodiment. The compiler system 148D is realized by the program 51 being executed by the control unit 510. That is, the program 51 includes a compiler system 148D.

  Referring to FIG. 23, compiler system 148D differs from compiler system 148 in FIG. 3 in that it includes compiler 149D instead of compiler 149. Since other configurations are the same as those of the compiler system 148, detailed description will not be repeated.

(Input of logical unguaranteed conditions)
FIG. 24 is a diagram illustrating a configuration of the compiler 149D according to the second modification of the third embodiment.

  Referring to FIG. 24, compiler 149D is different from compiler 149C in FIG. 18 in that it further includes a reception unit 189D. Since the other configuration is the same as that of compiler 149C, detailed description will not be repeated. Each unit in the compiler 149D is realized as a program module.

  The accepting unit 189D accepts an instruction from the outside. Specifically, accepting unit 189D accepts logical unguaranteed condition 161 indicated by the accepted instruction. The logic unguaranteed condition 161 accepted by the accepting unit 189D is a condition that does not require logic guarantee. The reception unit 189D transmits the received logical unguaranteed condition 161 to the logical unguaranteed optimization unit 185.

  As an example, the accepting unit 189D accepts the logical unguaranteed condition 161 indicated by the command line instruction. The command line instruction is an instruction as a compiler option. The command line instruction is performed, for example, when the programmer operates the keyboard 551.

  For example, the accepting unit 189D accepts the logic unguaranteed condition 161 indicated by the instruction by the #pragma instruction (see FIG. 7) described in the source program 141. In this case, the accepting unit 189D accepts the logic unguaranteed condition 161 from the source program 141.

  Note that each unit in the compiler 149D performs the same processing as in the third embodiment, and thus detailed description will not be repeated.

  That is, the logic unguaranteed optimization unit 185 performs a logic unguaranteed optimization process based on the logic unguaranteed condition 161 indicated by the instruction received by the accepting unit 189D for the first intermediate code. That is, the logical unguaranteed optimization unit 185 generates a fourth intermediate code by performing a logical unguaranteed optimization process that does not guarantee the logical unguaranteed condition 161 on the first intermediate code.

  As mentioned above, although the compile system in each embodiment of this invention was demonstrated based on embodiment, this invention is not limited to the said embodiment. For example, the optimality attainment information 142 is not limited to the optimality attainment based on the number of cycles. If the information is useful for tuning the instruction size, stack size, etc., the optimality attainment based on other parameters is obtained. It may be the information shown.

  In the process of S34 in FIG. 6 of the first embodiment, the comparison target is not limited to the IPC, and may be other parameters as long as the information is useful for performance comparison such as register use efficiency. .

  Also, what is to be compared by each of the optimality achievement level analysis unit 186A in FIG. 10 and the optimality achievement level analysis unit 186C in FIG. 18 is not limited to the number of cycles. It may be.

  In addition, the number of cycles of the target point of the optimality achievement level information that is the tuning point is an example. Besides the number of cycles, there are various instructions such as the number of instructions, code size, memory size, bus occupancy, cache hit rate, and compile time. Needless to say, there is an optimality viewpoint.

  Note that the present invention can be realized not only as a compiler that generates such characteristic information, but also as a compile device including characteristic means for the compiler to function the computer, It can also be realized as a compilation method with steps.

  It goes without saying that such a compiler can be distributed via a recording medium such as a CD-ROM or a transmission medium such as the Internet.

  As described above, the compiler or the compiler system according to the present invention has been described based on the embodiments. However, the present invention is not limited to these embodiments. Unless it deviates from the meaning of this invention, the form which carried out various deformation | transformation which those skilled in the art can think to this embodiment, or the structure constructed | assembled combining the component in different embodiment is also contained in the scope of the present invention. .

  The embodiment disclosed this time should be considered as illustrative in all points and not restrictive. The scope of the present invention is defined by the terms of the claims, rather than the description above, and is intended to include any modifications within the scope and meaning equivalent to the terms of the claims.

  The present invention can be used as a program conversion device and a program conversion system that support efficient tuning of a source program.

  Further, the present invention can be applied to a compiler that outputs optimality reachability information, an OS (Operating System), a process executed by a processor, and the like.

148, 148A, 148B, 148C, 148D Compiler system 149, 149A, 149B, 149C, 149D Compiler 150 Assembler 151 Linker 160 Relaxation specific condition 161 Logical unguaranteed condition 182 Parsing unit 183 Specific condition relaxation optimization unit 184 Logic assurance optimization Unit 185 logic unguaranteed optimization unit 186, 186A, 186C optimality reachability analysis unit 188 code output unit 189, 189D reception unit 500 computer 510 control unit

Claims (13)

A program conversion device that converts a source program written in a high-level language into a code for a target processor,
An intermediate code generator for generating a first intermediate code from the source program;
An optimization unit that generates a second intermediate code by performing an optimization process on the first intermediate code according to the target processor;
A program conversion apparatus comprising: an analysis unit that analyzes the performance of the second intermediate code and outputs optimum reachability information indicating a result of the performance analysis. The program conversion device further includes:
A specific condition relaxation optimization unit that generates a third intermediate code by performing a specific condition relaxation optimization process that is an optimization process in which a specific condition is relaxed for the first intermediate code;
The analysis unit further analyzes the performance of the third intermediate code and outputs the optimality attainment information indicating the analysis results of the performance of the second intermediate code and the third intermediate code.
The program conversion apparatus according to claim 1. The specific condition relaxation optimizing unit further outputs information on a condition in which the specific condition is relaxed,
The program conversion apparatus according to claim 2. The program conversion device further includes:
It has a reception unit that accepts instructions,
The specific condition relaxation optimization unit performs the specific condition relaxation optimization process based on a condition indicated by an instruction received by the reception unit;
The program conversion apparatus according to claim 2. The instruction received by the reception unit is an instruction by a command line.
The program conversion apparatus according to claim 4. The instruction received by the reception unit is an instruction included in the source program.
The program conversion apparatus according to claim 4. The program conversion device further includes:
A logic unguaranteed optimization unit that generates a fourth intermediate code by performing a logic unguaranteed optimization process that is an optimization process that does not guarantee the logical correctness of the first intermediate code;
The analysis unit further analyzes the performance of the fourth intermediate code and outputs the optimality attainment information indicating the analysis results of the performance of the second intermediate code and the fourth intermediate code.
The program conversion apparatus according to claim 1. The logic unguaranteed optimization unit further outputs information on conditions that do not guarantee the validity of the logic,
The program conversion apparatus according to claim 7. The program conversion device further includes:
It has a reception unit that accepts instructions,
The logical unguaranteed optimization unit performs the logical unguaranteed optimization process based on a condition that does not require a logical guarantee indicated by the instruction received by the accepting unit.
The program conversion apparatus according to claim 7. The instruction received by the reception unit is an instruction by a command line.
The program conversion apparatus according to claim 9. The instruction received by the reception unit is an instruction included in the source program.
The program conversion apparatus according to claim 9. The optimality reachability information at least indicates the optimal degree of the second intermediate code for the target processor;
The program conversion apparatus according to claim 1. A program conversion system for converting a source program written in a high-level language into a machine language code for a target processor,
An intermediate code generation unit for generating a first intermediate code from the program;
An optimization unit that generates a second intermediate code by performing an optimization process on the first intermediate code according to the target processor;
Analyzing the performance of the second intermediate code to output optimality achievement information indicating the result of the performance analysis; and
A machine language code generation unit that generates a machine language code that operates on the target processor using a file based on the second intermediate code.

Images