JP2018156568A - Compilation device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a compilation device capable of detecting an insertion leakage of dummy read corresponding to a write instruction when compiling a source program.SOLUTION: A compilation device in an embodiment includes: a write detection part configured to detect a write instruction in a source program; a read detection part configured to detect a read instruction after the write instruction is detected; and a determination part configured to determine whether the writing area is specified by the write instruction, whether a read-out region is specified by the read instruction and whether the read-out region coincide with the writing area.SELECTED DRAWING: Figure 5

Description

  The embodiment relates to a compiling device for compiling a source program.

  A source program written in a high-level language such as C language is compiled and converted into an object program. Depending on the specifications of the processor that executes this compile processing, when a certain core (module) in the source program writes a value to the memory or register, it cannot be guaranteed that the writing is completed immediately after the write command, and immediately after the write command. When another core (module) reads a value, a value before writing (previous value) may be read.

  As a countermeasure, there is a technique in which after a certain core (module) writes to the memory, the same core (module) reads a value from the same memory area to guarantee the completion of the writing. Such reading necessary to guarantee the completion of writing is called “dummy read”.

JP 2000-305809 A Japanese translation of PCT publication No. 2004-520463 JP-A-1-76129

  Provided is a compiling device that can detect a dummy read insertion omission corresponding to a write instruction when compiling a source program.

  The compiling apparatus according to the embodiment includes a write detection unit that detects a write command in a source program, a read detection unit that detects a read command after the write command is detected, and a write area specified by the write command, A read area is designated by a read command, and a determination unit that determines whether the read area matches the write area.

FIG. 1 is a diagram showing a program development flow. FIG. 2 is a diagram illustrating a hardware configuration of the compiling apparatus according to the first embodiment. FIG. 3 is a diagram showing a compile process for converting a source program into an object program in the first embodiment. FIG. 4 is a flowchart showing details of code generation during the compilation process shown in FIG. FIG. 5 is a flowchart showing a dummy read check process during the code generation process shown in FIG. FIG. 6 is a diagram showing an example of a table generated by the dummy read check process shown in FIG. FIG. 7 is a flowchart showing details of a lead leak check during the dummy read check process. FIG. 8 is a flowchart showing the dummy read check process in the first modification of the first embodiment. FIG. 9 is a diagram illustrating an example of a program to which the first modification of the first embodiment is applied. FIG. 10 is a diagram illustrating an example of a table generated by the dummy read check process in the first modification of the first embodiment. FIG. 11 is a diagram illustrating a program example to which the second modification of the first embodiment is applied. FIG. 12 is a diagram illustrating an example of a table generated by the dummy read check process in the second modification of the first embodiment. FIG. 13 is a flowchart illustrating a dummy read check process according to the second embodiment. FIG. 14 is a flowchart showing details of the read leak check during the dummy read check process shown in FIG. FIG. 15 is a diagram illustrating a program example to which the modification of the second embodiment is applied. FIG. 16 is a flowchart illustrating a dummy read check process according to the third embodiment. FIG. 17 is a diagram showing an example of a table generated by the dummy read check process shown in FIG. FIG. 18 is a flowchart showing the processing of the fourth embodiment.

  Hereinafter, embodiments will be described with reference to the drawings. In the following description, components having the same functions and configurations are denoted by the same reference numerals. In addition, each embodiment shown below exemplifies an apparatus and a method for embodying the technical idea of this embodiment, and the material, shape, structure, arrangement, and the like of the components are as follows. It is not something specific.

  Each functional block can be realized as hardware, computer software, or a combination of both. It is not essential that each functional block is distinguished as in the following example. For example, some functions may be executed by a functional block different from the illustrated functional block. Furthermore, the illustrated functional block may be divided into smaller functional sub-blocks.

1. First Embodiment A program executed on a processor is developed with a flow as shown in FIG. 1, for example.
(1) A program developer creates a source file (source program).
(2) A compiling device having a compiler compiles a source file and generates an executable file (or object program).
(3) The executable file is placed in the memory on the processor, and various applications are executed.

  The source program is compiled by a compiling device, and an intermediate language file is generated and an executable format file is generated via a linker. A compiling device for compiling a source program will be described below.

1.1 Configuration of Compiling Device FIG. 2 is a diagram illustrating a hardware configuration of the compiling device according to the first embodiment. The compiling device 10 includes a computer such as a general-purpose computer, a workstation, and a personal computer. As illustrated in FIG. 2, the compiling device 10 includes a CPU (Central Processing Unit) 11, a RAM (Random Access Memory) 12, a ROM (Read Only Memory) 13, and an input / output unit 14. The CPU 11, RAM 12, ROM 13, and input / output unit 14 are connected to each other by a bus 15.

  CPU11 controls each part of hardware according to the control program memorize | stored in ROM13, for example. The CPU 11 executes a compile process for the source program according to the compile program. The compile program is stored in the ROM 13, for example, and is loaded into the RAM 12 via the bus 15 at the time of activation.

  The RAM 12 temporarily stores various data generated when the CPU 11 executes the compile program, for example, intermediate codes and tables. The RAM 12 includes, for example, SRAM (Static RAM), DRAM (Dynamic RAM), flash memory, or the like.

  The ROM 13 stores, for example, a control program and a compile program.

  The input / output unit 14 includes an input unit that receives signals and data from an external device or user, and an output unit that outputs signals and data to the external device or user. The input unit receives, for example, a source program, a compile program, and an operation instruction from a user from an external device. The output unit outputs data processed by the CPU 11 or an object program, data stored in the RAM 12, and the like.

1.2 Operation of Compiling Device Next, a procedure of compile processing for converting a source program into object code will be described. FIG. 3 shows a compiling process for converting a source program into an object code (object program) such as a machine language. This compilation process is executed by the CPU 11.

  For example, the source program P 1 is input from the input / output unit 14 and stored in the RAM 12. The source program P1 is described in a high-level language such as C language.

  First, lexical analysis is performed on the source program P1 (step S1).

  Next, it is analyzed whether or not the lexical analysis result in step S1 is grammatically correct. That is, it analyzes whether the lexical word divided | segmented by step S1 follows a syntax rule, and produces | generates syntax analysis information (step S2).

  Subsequently, an intermediate code is generated based on the syntax analysis information (step S3). Further, the intermediate code is converted to optimize the intermediate code (step S4).

  Next, an object code such as a machine language is generated from the optimized intermediate code (step S5). Details of this code generation processing will be described later.

  Subsequently, the object code is optimized so that high-speed execution is possible (step S6). Further, the optimized object code P2 is output (step S7).

  In the present embodiment, in the “code generation” process shown in FIG. 3, a dummy lead insertion omission is checked, and if there is an omission, a warning is output (hereinafter referred to as a dummy read check). . The dummy read check may be executed by another process such as “syntax analysis” or “intermediate code optimization”.

  In the above description, steps S1 to S7 have been described as processing executed by the CPU 11. However, steps S1 to S7 are each a part (module) of a compile program as a “lexical analysis unit”, “syntax analysis unit”, “intermediate analysis unit”. It can also be understood as “code generation unit”, “intermediate code optimization unit”, “code generation unit”, “code optimization unit”, and “code output unit”.

  FIG. 4 is a flowchart showing details of code generation (step S5) during the compilation process shown in FIG. This code generation process is executed by the CPU 11.

  First, a basic block is created from the intermediate code optimized by the intermediate code optimization (step S4) (step S11). The intermediate code consists of an intermediate language between a high-level language (for example, C language) and a machine language. The intermediate code is obtained by dividing a program written in a high-level language into a single process. The basic block refers to a block composed of continuous intermediate codes separated by branches and function calls and in which processing is not interrupted.

  Next, a flow graph is created from the basic block (step S12). A flow graph is a combination of basic blocks. You can follow the flow of data access with the flow graph.

  Next, a dummy read check is performed on the intermediate code in the flow graph (step S13). The dummy read check requires basic block and flow graph information, and is executed after the flow graph is created. Details of the dummy read check will be described later.

  Next, register allocation is executed (step S14). Here, the virtual register is assigned to the register of the CPU 11. Further, an object code is generated based on the basic block and the flow graph (step S15).

  Note that the dummy read check may be executed after the creation of the flow graph, after register allocation, or after object code generation.

1.2.1 Dummy Read Check In the first embodiment, the intermediate code is analyzed in units of basic blocks, and dummy lead insertion leakage is checked. The procedure for checking the dummy lead insertion leakage in the basic block will be described below. In order to facilitate insertion and confirmation of dummy reads when creating a source program, it is appropriate to place dummy reads immediately after a write command, and in many cases, they are actually placed immediately after a write. For this reason, it is effective to check for dummy lead insertion omission in units of basic blocks.

  FIG. 5 is a flowchart showing a dummy read check process during the code generation process shown in FIG. FIG. 6 is a diagram illustrating an example of a table generated by the dummy read check process. This dummy read check process is executed by the CPU 11.

  When the dummy read check is started, first, the table P3 used for checking the dummy read is initialized (step S101). As shown in FIG. 6, the table P3 stores information such as an intermediate code of a write process (write instruction), a write destination address, the number of reads, and a pointer to the next table. The table P3 is generated in the RAM 12.

  Next, the intermediate code in the basic block is sequentially searched to determine whether or not the intermediate code is a write process (write instruction) (step S102). If the intermediate code is a write process, it is determined whether or not there is already a table in which an address that is the same as (or coincides with) the write destination address is already recorded (step S103).

  If there is already a table in which the same address is recorded in step S103, the read count of the address in the table is set to “0” (step S104). On the other hand, if there is no table in which the same address is recorded, the address is stored in a new table (step S105). Thereafter, the process proceeds to step S106.

  As shown in step S104, when there are multiple writes to the same address, it is necessary to check whether there is a dummy read after the last write. For example, in the case of the first write → first read → second write, the first read does not become the second dummy read. For this reason, the table is searched even during writing, and the number of reads is cleared to “0” when there is a write to the same address.

  Next, when the intermediate code is not a write process in step S102, it is determined whether the intermediate code is a read process (read instruction) (step S107). If the intermediate code is a read process, it is determined whether the read destination address is the same as the write destination address stored in the table (step S108).

  If the addresses are the same in step S108, the read count is incremented by "1", that is, the read count is incremented. (Step S109). Thereafter, the process proceeds to step S106. On the other hand, if the addresses are not the same, the process moves to the next intermediate code (step S110) and returns to step S102.

  If the intermediate code is not a read process in step S107, the process proceeds to step S106.

  In step S106, it is determined whether all intermediate codes in the basic block have been examined. If all the intermediate codes have not been checked, the process proceeds to the next intermediate code (step S110) and returns to step S102. Thereafter, the processing after step S102 is repeated.

  On the other hand, if all the intermediate codes have been checked in step S106, it is checked whether or not there is a dummy lead insertion leak (hereinafter referred to as a lead leak check) (step S111). In the read leakage check, the table P3 in which the write destination address is stored is referred to in order. As a result of referring to the table, when the number of reads is “0”, it is determined that there is a dummy lead insertion omission and a warning signal is output. Details of the lead leakage check will be described later. Thereafter, the dummy read check ends.

  FIG. 7 is a flowchart showing details of the lead leak check during the dummy read check process. In this lead leak check, the table P3 recorded in the process of FIG.

  First, it is determined whether or not all the tables P3 recorded in the process of FIG. 5 have been referenced (step S121). That is, it is determined whether or not the reference target table P3 is over. If the table P3 is not over, the number of reads in the table P3 is determined (step S122).

  If the number of reads is zero in step S122, it is determined that there is a dummy lead insertion omission and a warning signal is output (step S123). Thereafter, the process proceeds to step S124. On the other hand, if the number of reads is one or more, it is determined that the necessary dummy lead is inserted, and the process proceeds to step S124.

  In step S124, the reference target is moved to the next table, and the process returns to step S121. And the process after step S121 is repeated.

  If all the tables P3 have been referenced in step S121, the lead leakage check process ends.

  In the dummy read check process shown in FIG. 5, whether or not the write address and the read address are the same is handled as follows. If the numerical values of the write and read addresses are the same, it is determined that they are the same address. If the write and read addresses are the same variable, it is determined that they are the same address. If the write and read addresses are different elements in the same array, the addresses are determined to be the same. Furthermore, if the write and read addresses are the same structure, union, and different members of the bit field, the addresses are determined to be the same.

  Further, the table P3 illustrated in FIG. 6 may hold “a pointer to an intermediate code for write processing”. The pointer to the intermediate code of the write process is information necessary for deriving the line number on the source program from the intermediate code and using it as a warning message. However, it is unnecessary if the line number is not output in the warning message.

  The “write destination address” in the table P3 is necessary for comparison with the write destination address and the read destination address. However, if this is the case, it can be derived from the “pointer to the intermediate code for write processing”, so only either the “pointer to the intermediate code for write processing” or the “write destination address” is retained. May be.

1.2.2 Modification 1 of dummy lead check
In the first embodiment described above, it is determined that access to the same variable indicating the write destination and the read destination is access to the same area. In practice, it is determined that accesses within the same target (access unit defined for each processor) are accesses to the same area. As a compiling device, whether or not they are the same target is determined as whether or not they are the same section (unit for assigning data to memory).

In the first modification, if the write destination variable and the read destination variable are arranged in the same section, it is regarded as an access to the same area. In the first modification, differences from the first embodiment will be mainly described. FIG. 8 is a flowchart showing a dummy read check process in the first modification. FIG. 9 is a diagram illustrating a program example to which the first modification is applied. FIG. 10 is a diagram illustrating an example of a table generated by the dummy read check process.

  In the flowchart shown in FIG. 8, it is determined whether or not the intermediate code is a write process (step S102). If the intermediate code is a write process, it is determined whether or not there is already a table P4 that records the same section as the section in which the write destination variable is arranged (step S103A).

  If there is already a table P4 in which the same section is recorded in step S103A, the number of reads in that table is set to 0 (step S104). On the other hand, if there is no table in which the same section is recorded, the section is stored in a new table (step S105A). Thereafter, the process proceeds to step S106.

  If the intermediate code is not a write process in step S102, it is determined whether the intermediate code is a read process (step S107). When the intermediate code is read processing, it is determined whether or not the section in which the read destination variable is arranged is the same as the write destination section stored in the table P4 (step S108A).

  If the read destination and write destination sections are the same in step S108A, the read count is incremented by “1”, that is, the read count is incremented. (Step S109). Thereafter, the process proceeds to step S106. On the other hand, if the sections are not identical, the process moves to the next intermediate code (step S110) and returns to step S102. Other processes are the same as those shown in FIG.

  Referring to the example program shown in FIG. 9, the variables ary1 and ary2 are arranged in the same section. Since there is a read after a write to a variable arranged in the same section, in this program example, it is determined that there is a dummy read, that is, there is no dummy read insertion omission. For this determination processing, the “write destination address” shown in FIG. 6 is changed to “arrangement section name” in the table P4 shown in FIG.

  In the first modification, since the dummy leak insertion omission determination corresponding to the write command can be performed in section units, the erroneous determination of dummy read insertion omission can be reduced as compared with the first embodiment. Thereby, it is possible to reduce the man-hours required by the program developer for the warning output by the compiling device of the first modification.

1.2.3 Modification 2 of dummy lead check
In the second modification, the variable ary1 and the variable ary2 are arranged in different sections. In this case, in Modification 1, it is determined that there is a dummy lead insertion leak (no dummy lead), but it may be determined that there is no dummy lead insertion leak (there is a dummy lead).

  FIG. 11 is a diagram illustrating a program example to which the second modification is applied. FIG. 12 is a diagram illustrating an example of a table generated by the dummy read check process.

  Referring to the program example shown in FIG. 11, the variables ary1 and ary2 are arranged in different sections. In this state, the dummy read check of the first modification determines that there is no dummy read.

  Therefore, it is specified that section DATA_SEC1 and section DATA_SEC2 are allocated to the same memory area. For example, the section DATA_SEC1 and the section DATA_SEC2 are specified by “#pragma same_region”.

  The compiler program includes a process for determining whether or not a designation for allocating section DATA_SEC1 and section DATA_SEC2 to the same memory area is in the source program. If it can be determined by this determination that the two sections are assigned to the same memory area, the variables ary1 and ary2 can be recognized as the same memory area. Thereby, it can be determined that the reading of the variable ary2 is a dummy read corresponding to the writing of the variable ary1.

1.3 Effects of First Embodiment According to the first embodiment, it is possible to provide a compiling device that can detect a dummy read insertion omission corresponding to a write instruction when compiling a source program.

  Below, the effect of 1st Embodiment is explained in full detail.

  If a dummy read is not inserted after the write instruction in the source program, the program operating on the processor may not operate normally. On the other hand, because the processor specifications are complex and it is difficult to identify the locations where dummy leads need to be inserted, the insertion of dummy leads may be leaked, or the performance of a program may be degraded by inserting unnecessary dummy leads.

  In the present embodiment, since the dummy lead insertion omission in the source program can be detected, the quality of the source program can be improved. Furthermore, the development efficiency from the source program to the completion of the application software can be improved.

  In addition, the program developer can easily confirm the necessary leakage of dummy leads, and can prevent troubles caused by the leakage of dummy leads after shipment.

  In the present embodiment, the following dummy lead insertion leakage can be detected. For example, after writing to the memory, the dummy read is not inserted before calling the function to release the semaphore, or dummy read is leaked due to the dummy read processing without volatile modification and being deleted by optimization. For example, a dummy read is not inserted due to the completion of processing of the function immediately after the write operation.

2. Second Embodiment A compiling device according to a second embodiment will be described. In the first embodiment, the dummy lead insertion leakage is checked for each basic block. In the second embodiment, after all basic blocks are searched, the dummy lead insertion leakage is checked. Since the configuration of the second embodiment is the same as the configuration of the first embodiment shown in FIGS. 2, 3, and 4, description thereof is omitted. Below, a different point from 1st Embodiment is mainly demonstrated.

2.1 Dummy Read Check FIG. 13 is a flowchart showing a dummy read check process according to the second embodiment. In this process, the table P3 created for each basic block is stored in the RAM 12.

  When the dummy read check is started, first, the table P3 used for checking the dummy read is initialized (step S101).

  Next, the intermediate code in the basic block is sequentially searched to determine whether or not the intermediate code is a write process (write instruction) (step S102). If the intermediate code is a write process, it is determined whether there is already a table in which the same address as the write destination address is recorded (step S103).

  If there is already a table P3 in which the same address is recorded in step S103, the read count of the address in the table is set to “0” (step S104). On the other hand, if there is no table in which the same address is recorded, the address is stored in a new table (step S105). Thereafter, the process proceeds to step S106.

  Next, when the intermediate code is not a write process in step S102, it is determined whether the intermediate code is a read process (read instruction) (step S107). If the intermediate code is a read process, it is determined whether the read destination address is the same as the write destination address stored in the table (step S108).

  If the addresses are the same in step S108, the read count is incremented by "1", that is, the read count is incremented. (Step S109). Thereafter, the process proceeds to step S106. On the other hand, if the addresses are not the same, the process moves to the next intermediate code (step S110) and returns to step S102.

  If the intermediate code is not a read process in step S107, the process proceeds to step S106.

  In step S106, it is determined whether all intermediate codes in the basic block have been examined. If all the intermediate codes have not been checked, the process proceeds to the next intermediate code (step S110) and returns to step S102. Thereafter, the processing after step S102 is repeated.

  On the other hand, if all the intermediate codes have been checked in step S106, it is determined whether all the basic blocks have been checked (step S201). If all the basic blocks have not been checked, the process proceeds to the next basic block (step S202) and returns to step S102. Thereafter, the processing after step S102 is repeated.

  If all the basic blocks have been checked in step S201, a lead leak check, that is, whether there is a dummy lead insertion leak is checked (step S111). Details of the lead leakage check will be described later. Thereafter, the dummy read check ends.

  FIG. 14 is a flowchart showing details of a read leak check during the dummy read check process. In this lead leak check, the tables recorded in the processing of FIG.

  First, it is determined whether or not the basic block table P3 of all the dominant clauses recorded in the process of FIG. 13 has been referenced (step S211). That is, it is determined whether or not the reference target table is over. If the table to be referenced is not the end, the number of reads in the table is determined (step S212). Note that a dominant clause is a basic block that is guaranteed to pass through a certain basic block.

  If the number of reads is 0 in step S212, it is determined whether or not there is a function call in the basic block that is the dominating clause of the basic block. If there is a function call, the process proceeds to step S215. On the other hand, if there is no function call, the number of reads in the table of the basic block of the dominant clause is determined (step S214). If the number of reads is 0, the process proceeds to step S215.

  In step S215, it is determined whether or not the dominating clause is the last dominating clause. If it is the last dominant node, it is determined that there is a dummy lead insertion omission and a warning signal is output (step S217). Then, it returns to step S211 and repeats the process after step S211.

  On the other hand, if it is not the last dominant node in step S215, the process proceeds to the next dominant node (step S216), returns to step S213, and repeats the processing from step S213 onward.

  If the number of reads is one or more in steps S212 and S214, the process moves to the next basic block table (step S218), returns to step S211 and repeats the processes in and after step S211.

  In step S211, when the investigation of the basic block tables of all the control clauses is completed, the lead leakage check process is terminated.

  As described above, the lead leakage check in the second embodiment is executed as follows.

  When checking whether or not there is a dummy lead insertion omission in a basic block, the basic block table is first checked. If there is no dummy read in the basic block, the table of the basic block that is the dominant node of the basic block is checked.

  If there is a read at the same address as the write destination address, it is determined that there is no dummy lead insertion omission, that is, there is a dummy read. When there is no read at the same address as the write destination address (when there is no table or when the number of reads in the table is 0), it is determined that there is a dummy read insertion omission, that is, there is no dummy read.

  Also, if there is a function call in the dominant clause of the basic block, it is unclear whether there is a dummy read, so the process moves to the next dominant clause. The basic block of all the dominant clauses of the basic block is searched, and if the read count is “0”, it is determined that there is no dummy read.

2.2 Modification of dummy read check In the dummy read check of the second embodiment, it is determined that there is a dummy lead insertion omission when there is a function call in the dominant clause, but in this modification, it is called by a function call. The area accessed by the function to be accessed is specified by the source program. As a result, it is possible to determine whether or not the write destination access area (memory area) and the access area of the function to be called are the same as those in the first embodiment.

  FIG. 15 is a diagram illustrating a program example to which the modification is applied. As a method for specifying an area to be accessed, for example, there are a function modifier and a #pragma directive. Referring to the example program shown in FIG. 15, the function func1 reads the data in the section DATA_SEC1, and the function func2 reads the data in the section DATA_SEC2. Thereafter, by calling the function func1, it is determined that there is a dummy read corresponding to writing to the variable ary1 placed in the section DATA_SEC1. Similarly, by calling the function func2, it is determined that there is a dummy read corresponding to writing to the variable ary2 placed in the section DATA_SEC2.

  As described above, in the modification, the area accessed by the call function in the source program of the application is clearly indicated by the program statement in the source program. Then, the compiling device interprets it, and checks whether or not dummy leads are inserted, that is, whether or not dummy leads are present.

  In this modification, if a function prepared as a countermeasure against dummy read insertion (for example, the function qualifier or #pragma instruction) is called immediately after a write instruction, it is determined that a dummy read is inserted, and a warning output target Don't make it. Accordingly, erroneous determination of dummy lead insertion omission can be reduced, so that the number of man-hours required by the program developer for the warning output by the compiling device of the modified example can be reduced.

2.3 Effects of the Second Embodiment According to the second embodiment, it is possible to provide a compiling device that can detect a dummy read insertion omission corresponding to a write instruction when compiling a source program.

  Further, when there is no dummy read corresponding to the write command in the basic block, the search range of the dummy read can be extended to the basic block that is the dominant node of the basic block. For this reason, the detection accuracy of dummy lead insertion leakage can be improved.

3. Third Embodiment Library functions defined in the programming language standard include functions having a function of writing to a memory, such as “memcpy” and “memset”. In the third embodiment, when a function having a function of writing to a memory such as “memcpy” or “memset” is used, a dummy read check is performed on the basic block (and its dominant clause) immediately after the function call. It is an example. Since the configuration of the third embodiment is the same as the configuration of the first embodiment shown in FIGS. 2, 3, and 4, description thereof is omitted. Below, a different point from 1st Embodiment is mainly demonstrated.

3.1 Dummy Read Check For a library function having a source program writing function, the compiling device can recognize that an argument defined in the standard is a pointer to a memory write destination. In the third embodiment, it is checked whether or not there is a dummy read insertion omission with respect to the memory write destination of the library function.

  The basic block for searching for a dummy read for the memory area written by the library function is the basic block immediately after the function call and its dominant clause.

  Since the language standard defines that the first argument is the write destination, the first argument is defined in the table as the write destination. Other table definitions are the same as those in the first embodiment.

  FIG. 16 is a flowchart illustrating a dummy read check process according to the third embodiment. FIG. 17 is a diagram illustrating an example of a table generated by the dummy read check process.

  In step S102A, it is determined whether the intermediate code in the basic block is a function having a write function. If the intermediate code is a function having a write function, it is determined whether or not there is already a table P5 in which the same argument as the write destination argument is recorded (step S103B).

  If there is already a table in which the same argument is recorded in step S103B, the number of times of reading the argument in the table is set to “0” (step S104). On the other hand, if there is no table in which the same argument is recorded, the argument is stored in a new table (step S105B). Thereafter, the process proceeds to step S106.

  On the other hand, if the intermediate code is not a function having a write function in step S102A, it is determined whether the intermediate code is a read process (read instruction) (step S107). If the intermediate code is a read process, it is determined whether the read destination address is the same as the address indicated by the first argument of the write destination stored in the table P5 (step S108B).

  In step S108B, when the addresses are the same, the read count is incremented by “1”, that is, the read count is incremented. (Step S109). Thereafter, the process proceeds to step S106. On the other hand, if the arguments are not the same, the process moves to the next intermediate code (step S110) and returns to step S102.

  Other processes are the same as those shown in FIG.

3.2 Effects of the Third Embodiment According to the third embodiment, it is possible to provide a compiling device that can detect a dummy read insertion omission corresponding to a write instruction when compiling a source program.

  Furthermore, for functions defined in the language standard, dummy lead insertion omission can be checked according to the function specifications. As a result, it is possible to detect a dummy lead insertion leakage that could not be detected in the first embodiment.

4). Fourth Embodiment The fourth embodiment is an example in which it is possible to select whether or not to execute the dummy read check in the first to third embodiments described above.

  FIG. 18 is a flowchart showing the processing of the fourth embodiment. As shown in the figure, before the dummy read check process (step S13), a determination process (step S16) for determining whether or not to execute the dummy read check is provided. When executing the dummy read check, the process proceeds to the dummy read check as it is. On the other hand, if the dummy read check is not executed, the dummy read check is passed and the process proceeds to the register allocation process (step S14).

4.2 Effects of the Fourth Embodiment According to the fourth embodiment, it is possible to select whether or not to execute a dummy read check. Thereby, the freedom degree of a compilation process improves. Furthermore, when the dummy read check is not executed, the time required for the compilation process can be shortened.

5. Other Modifications Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

  DESCRIPTION OF SYMBOLS 10 ... Compile apparatus, 11 ... CPU, 12 ... RAM, 13 ... ROM, 14 ... Input-output part, 15 ... Bus.

Claims (7)

A write detector for detecting a write command in the source program;
A read detector for detecting a read command after the write command is detected;
A determination unit that determines whether a write area is specified by the write command, a read area is specified by the read command, and the read area matches the write area;
A compiling device comprising: When a write area by the write instruction is indicated by a first variable, a read area by the read instruction is indicated by a second variable, and the first variable and the second variable are different,
The determination unit determines whether or not a first section in which the first variable is arranged matches a second section in which the second variable is arranged,
2. The compiling apparatus according to claim 1, wherein the first section is a unit in which data is written to the write area by the write instruction, and the second section is a unit in which data is read from the read area by the read instruction. When the first section in which the first variable is arranged does not match the second section in which the second variable is arranged,
The compiling apparatus according to claim 2, wherein the determination unit determines whether or not the designation to allocate the first section and the second section to the same memory area is in the source program.   4. The compiling device according to claim 1, wherein the write instruction is an instruction by a function having a writing function defined by a language standard in which the source program is described. The source program is divided into basic blocks including intermediate code,
The compiling apparatus according to claim 1, wherein the write detection unit detects the write command for the basic block, and the read detection unit detects the read command for the basic block. . The source program is divided into a plurality of basic blocks including intermediate code, and the plurality of basic blocks includes a first basic block and a second basic block that always passes after passing through the first basic block,
The write detector detects the write command for the first basic block and the second basic block, and the read detector detects the read command for the first basic block and the second basic block. The compiling apparatus according to claim 1, wherein detection is performed. A storage unit that stores the number of times the read command having the read area that matches the write area is detected after the write instruction is detected;
7. The determination unit according to claim 1, wherein the determination unit determines whether or not the read instruction having the read area that matches the write area of the write instruction is in the source program based on the number of the read instructions. The compiling device according to any one of the above.