JPH10275088A - Link optimizing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide the optimizing method by a linker for enabling reference to different external variables by registers less than the external variables. SOLUTION: When a load module is generated by the linker, respective source modules 201 to 203 are compiled by a compiler 204 to generate intermediate codes 207 to 209 and external symbol tables 210 to 212 in the module. Then the external symbol tables 210 to 212 and libraries 213 to 214 are read in by the linker 215 to generate an external symbol table 217. Further, the external symbol 217 and intermediate codes 207 to 209 are used to convert reference of external variables included in a specific address range determined by an object CPU into reference using one external variable by a base register common-use process 220. Lastly, a load module 223 is generated by a link process 222.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a link method for reducing the number of execution instructions in a computer.

[0002]

2. Description of the Related Art A compiler and a linker are used to create one load module from a plurality of source files. The compiler compiles each source file one by one and generates an object module corresponding to each source file. Then, the linker combines all the generated object modules and necessary libraries to generate a final load module.

[0003] Variables used in a source file can be classified as follows according to the scope of their use.

(1) Variables that are valid only within one function or procedure (2) Variables that are valid only within one module (3) Variables that are valid across modules Classification (1) and classification (2) The memory location (address) is determined at compile time, while the variable of category (3) is determined at link time at the time of linking. The variables of the category (3) are called external variables, and a table is provided for managing the memory locations of the external variables for each object module. The memory location management table is, for example, TOC (Table Of Contents).
The linker scans all memory location management tables of each object module and library to determine the memory location of each external variable, and writes the address of the determined external variable to the memory location management table.

Here, reference to an external variable through the TOC will be described. Since the memory location of the external variable is not determined at compile time, it must be indirectly performed through the TOC. FIG. 1 shows a general example of indirect reference of an external variable. The value 107 stored in the main memory 106 is the external variable A
And B. The object module 101 is roughly divided into a code section 102 storing a program and a data section 103 storing addresses of data and variables referred to by the program. For example, external variable A
Requires two instructions 108a and 109a. First, the instruction 110a loads the address 110a in the main memory where the external variable A is stored into the register r1. Next, the actual value of A is loaded into the register fr1 from the address loaded by the instruction 109a. In order to obtain the address where the external variable is stored, the instruction 108a uses a register RTOC (104) for holding the head address of the TOC area and an offset offs indicating the position in the TOC where the address of A is stored.
Add etA (110a). Similarly, the external variable B is referred to by the two instructions 108b and 109b. The offset in the TOC of external variable B is offset
B (110b), and the value of the variable is stored in 107b.

Normally, different external variables must be referred to through different external variable address holding registers. For example, FIG. 1 refers to two external variables A and B. For reference to these external variables, the external variables A
Use the address holding register r1 at 108a,
For the external variable B, the address holding register r2 is set to 108b.
You are using The addresses of the external variables A and B are determined at the time of linking. However, the addresses of the external variables can be changed depending on the order in which a plurality of object modules and libraries required at the time of linking are specified. Also, since register allocation is a process performed at the time of compilation, it is not possible to allocate a common address holding register to different external variables at the time of compilation.

However, if the variables whose memory locations are determined belong to the same specific address range, different variables can be referred to based on the specific memory location. Here, "belongs to a specific address range"
Is an instruction of the CPU for referring to the memory,
This means that the value falls within the memory range that can be represented by an immediate value (not an indirect value through a register, but an integer value itself). Within one module, it is guaranteed that variables declared in a C language structure or a FORTRAN language COMMON are consecutively arranged in memory in the order of declaration. Each element variable can be referred to using an offset from the base (the number of words from the base) based on the start address of the base. Compiler optimizations that take advantage of this fact are already well-known.

[0008] A method of optimizing at the time of linking and a method of integrating linking and compiling utilizing the fact that the memory location of an external variable is determined at the time of linking have been studied.
First, as prior art (1), A.I. Srivastava, D.S. W. W
all "Link-Time Optimization of Address Calcul
ation on a 64-bit Architecture "ACM SIGPL
There is AN '94. This is because, using the OS convention of unifying the external variable management table for each object module and giving one to the load module, direct external variable references instead of indirect references, that is, memory location management tables By writing the value of the variable itself instead of the address of the variable, unnecessary address calculation is omitted and execution performance is improved.

As the prior art (2), V.I. Santanam,
D. Odnert "Register Allocation Across Proce
dure and Module Boundaries "ACM SIGPLA
There is N'90. This groups a plurality of functions and allocates registers to external variables that are commonly referenced within the group. Where it is necessary to load the address of the external variable every time the function is called, the address of the external variable is loaded when the function in the group is called for the first time. Is omitted.

This method is divided into three phases: (1) a phase in which each source file is converted into intermediate code and, at the same time, program information on external variables and function calls is generated; and (2) a generated program It consists of a phase for allocating a register to an external variable while using information and outputting an object module, and (3) a phase for generating a final load module from each object module and library.

[0011]

In the prior art (1), the reference of the external variable table is changed from the indirect reference to the direct reference, so that two instructions can be reduced to one instruction. . However, if the OS that requires the object module to have an external variable table even after linking attempts to directly reference it, the value of one external variable will exist in multiple tables at the same time, and the value of the external variable It is necessary to rewrite all the values of the external variable table for each update, which causes a problem of deteriorating the performance.

The prior art (2) is intended to reduce the number of instructions for loading the address of an external variable. However, since one register must be allocated to each external variable, the number of registers becomes insufficient when a large number of external variables are used in a procedure. As a result, a large number of register recovery codes are generated, resulting in performance degradation.

In addition to the above-mentioned problems of the prior art, there are the following problems. Since the memory allocation between external variables used between modules cannot be determined at compile time, even if the external variables are finally arranged adjacently in memory, temporary reference must be made for each variable to refer to them. You have to prepare variables. If it is known in advance that the variable X is adjacent to the memory, for example, if the address of the variable X is P, the value of the variable Y should be able to be extracted by referring to the address P + 1.
Here, since the temporary variables are usually assigned to the registers of the CPU, an increase in the number of temporary variables means that many of the registers of the CPU having a limited number are required to be used. This limits the number of registers that can be used for other compilation important optimizations. When the number of registers is insufficient, a store instruction to save the value stored in the overflowing register to the main memory and a load instruction to restore the register value as necessary are generated. . As a result, the execution speed of the load module decreases due to the increase in the number of instructions. When such a save / restore instruction is generated in a loop, it causes a significant reduction in speed. When the number of save / restore instructions increases, the possibility of a cache miss also increases, which disrupts the flow of the CPU pipeline. As a result, the execution speed of the load module is further reduced.

[0014]

SUMMARY OF THE INVENTION In the optimization performed by the linker, the present invention provides external variables referenced in the module as inputs to the linker and libraries necessary for generating a load module, and cannot be determined at compile time. Find the addresses of all external variables.

By using the addresses of the external variables, if it is known that a plurality of external variables are included in the address range determined by the target CPU, it is conventionally necessary to use different temporary variables for different external variables. Can be referenced by a single temporary variable.

Therefore, a group of variables in a specific address range is obtained from the address of the external variable, and the intermediate code is converted so that the value of the external variable belonging to the group is referred to by one temporary variable.

As a result, the number of CPU registers that must be allocated to temporary variables can be reduced, and other optimized registers can be used.

[0018]

Embodiments of the present invention will be described below in detail.

FIG. 2 shows a configuration of a compiler and a linker according to the present invention.

Reference numerals 201 to 203 denote source modules necessary for creating a load module. Each source module is input to the compiler 204 one by one, and is processed independently. Inside the compiler 204, for example, the syntax analysis processing 204 is performed on the source module 201. In this process, an intermediate code that is easy to process inside the compiler is generated while detecting a syntax error in the source module. Subsequently, an optimization process 206 is performed to generate an intermediate code 207 and an internal module external symbol table 210 which are output from the compiler. The intermediate code is converted so as to be easily processed by the compiler, and at the same time, flows while changing the shape inside the compiler as an intermediate result of the optimization processing. The external symbol table in the module contains information on external symbols (variables and functions) referenced in the source module.

Intermediate codes 207 to 209 generated from all source modules and external symbol tables 210 to 212
And the libraries needed to generate the load module
213 to 214 are input to the linker 215. In the linker 215, the input external symbol table in the module, 207 to 209 and the library 21
An external symbol table 217 is generated from 3 to 214 by an external symbol table creation process 215. The external symbol table 217 contains information on all external variables required to create a load module. The external symbol table 217 and the intermediate codes 207 to 209 are optimized by the optimization processing 218. The optimization process includes several steps 219 to 221, among which there is a base variable unification process 220 according to the present invention.

The intermediate code obtained as a result of the optimization is combined by a link processing 222 to obtain a final load module 223.

FIG. 3 shows an example of a source module using external variables.

In 301, one element is a float of 4 bytes.
(Floating point) type, one-dimensional array AB with 100 elements
This indicates that an area is secured on the storage device using C as an external variable. These variables can be referenced from other source modules. This means that if you change the values of these variables, other modules can use the changed values. 302 to 307 are functions func1
Declare The declared function can be called from other functions, and the processing in the function is performed each time it is called. 303 declares that an int (integer) type variable i is used in the function func1. This variable is valid only within a function and cannot be referenced from other functions or other source modules. 304 to 306 are execution parts. Reference numerals 304 to 306 denote loops in which the value of A [i] + B [i] is calculated while changing i by 1 from 0 to 99, and the value is substituted for C [i].

The external variables A, B, and C declared in 301 are not always allocated continuously on the storage device.
They are not necessarily arranged in the order of declaration. This arrangement is determined by the linker.

FIG. 4 shows a configuration of a compiler according to the present invention.

The compiler 204 reads the source module 201 from the storage device 401, performs a syntax analysis process in step 205, converts the source module 201 into an intermediate code 402 that can be easily processed by the compiler, and is necessary for the optimization performed in the following steps. Information (for example, dependencies between variables). The details of this syntax analysis processing are described in, for example, "Eiho Cessie Ullman: Compiler 1 (Science Inc., 1990), pp. 30-74", and a description thereof will be omitted.

Next, at step 206, the intermediate code 4
02 and performs optimization processing, and outputs an improved intermediate code 207 and an external symbol table 210 inside the module. The optimization performed in step 206 performs optimization independent of the number of CPU registers. For example, optimization such as loop transformation and subexpression elimination. Such optimization is described, for example, in “Michael Wolfe: High Performan
ce Compilers ForParallel Computing (Addison-W
esley 1996) pp. 307-366 ", and a description thereof will be omitted.

The module internal symbol table 210 will be described with reference to FIG.

FIG. 5 shows an example of an intermediate code when the program of FIG. 3 is compiled by a conventional compiler. The intermediate code is first created by a parsing process, and changes in shape each time each optimization process is applied.

The intermediate code shown in FIG. 5 is represented by a graph in which basic blocks are connected by edges.

Reference numerals 501 to 505 are basic blocks. The basic block represents a series of code strings without branching or jumping in the middle, and is constituted by the syntax analysis processing 205. The side indicates the control flow of the basic block. For example, when the processing of the basic block 504 is completed,
Means that the process moves to By moving the process from 504 to 503, it can be seen that a loop is formed by 503 and 504.

FIG. 6 shows the contents of the basic block 502 in detail.

The basic block 502 is composed of four sentences. Each sentence uses a statement number 601, a sentence processing content 602, and a variable name 603 on the left side of the assignment statement and a variable on the left side when the sentence is an assignment statement. It consists of a sentence number list 604. The statement number 601 is a number uniquely assigned to one entire intermediate code. The processing content 602 is written in the address number 3 notation. The third address notation is described in, for example, "Eiho Cessie Ulman: Compiler 2 (Science Inc., 1990), pp. 567-568", and the description is omitted.

For example, reference numerals 605 to 608 show the contents of the basic block 502. The statement 605 means that 0 is substituted for the temporary variable t1. Here, the operator “: =” indicates that the value calculated on the right side is substituted for the variable on the left side.
The statement 606 means that the address of the variable A is substituted for the variable t2. The operator "&" indicates that the address on the storage device of the variable appearing in the operand of the operator is obtained.
Similarly, in statement 607, the address of variable B is assigned to variable t3,
At 608, the address of the variable C is substituted for the variable t4.

The operator "*" appearing in the basic block 504 is for taking the expression contained in the operand as an address on the storage device and extracting the value contained in the address. These "&" and "*" operators are the code part in Fig. 1.
These operators correspond to the 102 instructions 109a and 110a (or 109b and 110b), respectively, and these operators always appear in the intermediate code in order to determine the value of the external variable. That is, if an integer constant is included in the expression to which the operator “*” is applied, the constant will appear in the immediate portion of the generated instruction. Conversely, to specify an integer constant in the immediate part of the instruction, the integer constant may be placed in the expression of the "*" operator in the intermediate code.

FIG. 7 is an example of an external symbol table in the module.

The external symbol table in the module is created in step 206 from information such as variables and functions in the module managed by the compiler.

In the external symbol table in the module, the symbol name 701, the type 702 indicating whether the symbol is a variable or a function, and whether the symbol is defined in the module or used in another module is used. The reference format 703 indicates the size 704 of the area occupied by the variable in the storage device.

FIG. 8 shows the structure of the linker according to the present invention.

The linker 215 reads from the storage device 401 the external symbol tables 210 to 212 generated by the compiler and necessary libraries 213 to 214, and finally outputs one load module 222. In the external symbol table creation processing (step 216), the module internal symbol tables 210 to 212
And necessary libraries 213 to 214 are read and the external symbol table 21
Create 7. The external symbol table shows external symbol names and addresses representing positions on the storage device between the external symbols.
The contents of the external symbol table will be described with reference to FIG. Regarding the process of creating the external symbol table, see, for example, “Youichi Muraoka: Computer Architecture (Kindai Kagakusha 1985
Year) pages 66-73 ", and the description is omitted.

Next, in the optimization processing 217, the intermediate codes 207 to 209
And the libraries 213 to 214 are read and various optimizations 218 to 220 are performed. The optimization performed here relates to the register allocation of the CPU. In the optimization processing 217, the base register sharing processing 219 according to the present invention is performed.
The base register commonization is an optimization process performed before CPU register allocation, in which intermediate codes are converted based on the positional relationship between external variables so that a plurality of temporary variables can be referred to by one register. The flow of the base register sharing will be described in detail with reference to FIGS.

Thereafter, link processing 221 is performed based on the final intermediate codes 801 to 803, libraries 213 to 214, and external symbol table 217.
Generates the final load module 222. For code generation, see, for example, "Aho Sesi Ullman: Compiler 2 (Science Inc. 1990) No. 624-7.
Page 07 ", so the description is omitted.

FIG. 9 shows the contents of the external symbol table 217.

The external symbol table stores an external symbol name 901, a type 902 indicating whether the external symbol is a variable or a function, a size 903 indicating the size of the area occupied by the symbol in the storage device, and a location in the storage device where the symbol is stored. It consists of a position (address) 904 that indicates whether the

FIG. 10 is a flowchart showing the flow of the common use of the base variables according to the present invention.

The base variables are shared for each basic block included in the intermediate code. First, in step 1001, one intermediate code is taken, and one basic block is taken (step 1002). Check whether the address of the external variable is referenced in the fetched basic block (step 100
3) If it is included, the base variable for the external variable is obtained (step 1004), and the sentence using the value of the external variable is appropriately rewritten.

If the base variables can be standardized, some of the original statements become useless codes. Useless code is a statement that calculates a value that is never used in the program. Although different temporary variables are required to refer to the values of different variables (for example, the basic block 502 in FIG. 5), one temporary variable is sufficient due to the common base variable. Therefore, the effect of unifying the base variables can be improved by deleting the unnecessary code. Regarding the useless code deletion, for example, refer to “Aho Sesi Ullman: Compiler 2
(Science Inc., 1990), pp. 725-726 ", and a description thereof will be omitted.

When there is no reference to the address of the external variable in the basic block, or when the update of the statement using the value of the external variable is completed, it is checked whether or not the next basic block exists (step 1007). Returning to step 1002, if there is no next intermediate code, it is checked (step 1008). If there is an intermediate code, the process returns to step 1001; otherwise, the base variable sharing is terminated.

FIG. 11 shows a base variable table for each basic block.

The base variable table is created by the process described with reference to FIG. 12 (which describes step 1004 in detail).

A base variable table is an external variable serving as a base variable.
1101 is a position 1102 of the base variable in the storage device. 1103 is a list of external variables in a range that can be represented by the base variable.

FIG. 12 is a flowchart showing the process of obtaining the base variable in step 1004 of FIG.

First, take one external variable from the external symbol table
(Step 1201). Assuming that the extracted external variable name is X, a row equal to the external variable name X is found from the column of the symbol name 901 in the external symbol table 217, and when the column 904 of the row position is found, the position of the external variable X is found to be LX. I do. If X is already registered as a base variable in the base variable table (external variable X is registered in the column of variable name 1101 in the base variable table in FIG. 11) or registered as a variable that can be referred to by the base variable If there is any (external variable X is registered in the column of member 1103 of the base variable table in FIG. 11) (step 1202), the next external variable is searched (step 1207).

If X has not been registered in the base variable table, it is checked whether X can be a base variable. In step 1203, one base variable is extracted from the base variable table. Let Y and the position of the extracted variable be LY.

The size of the area on the storage device that can be represented by the immediate value of the instruction is determined by the target CPU of the load module to be finally created. This size is defined as disp.
If there are multiple external variables in the range that can be represented by disp, those external variables can all be referenced based on a certain point in the area. In the present embodiment, among the external variable groups that can be represented by the same base variable, the external variable that appears first in the basic block is registered as the base variable. That is, the difference between the registered position LY of the base variable Y and the position LY of the external variable Y currently being processed is disp.
If less, the variable Y can be represented using the variable X. This inspection is performed in step 1204.

If the condition of step 1204 is satisfied, X is registered in the base variable table as a member variable of Y (step 120).
Five).

If the condition of step 1204 is not satisfied, X
Is registered in the base variable table as a new base variable
(Step 1206).

When the above processing is completed, it is checked whether or not the next external variable is in the basic block (step 120).
7) If there is, return to step 1201 and repeat the above processing. If not, the base variable registration process ends.

FIG. 13 shows a flow of a process of updating the values of the external variables using the values of the base variables.

The initial state 1301 is an example of a typical intermediate code for obtaining the value of the element B [i] of the array as the temporary variable t4 when the external variable B is an array. In statement 1301a, the address of B is assigned to the temporary variable t1, in statement 1301b, the subscript value stored in the temporary variable t3 is added to the address of B, and in statement 1301c, the value of B [i] is assigned to the temporary variable t4. .

When the external variable B can be represented by the base variable A, that is, when B is registered as a member of A in the base variable table, B can be replaced with reference to A. Here, assuming that the difference between the position of B and the position of A is 400, it can be converted into 1302 by base variable conversion. That is, the expression targeted for the “&” operator in the statement 1302a is changed from B to A, and 400 is added.

When CPU instructions are generated for this statement 1302a, two instructions of addition and loading from the TOC are required. If the value "400" can be propagated to the statement 1302c referring to the array value, , 1302c can absorb “400” by the CPU instruction.

Since the propagation of the integer constant propagates the operand of the address addition, the statement 1302b
Even if there is such an addition, it can pass through as it is. In other words, the expression for the “*” operator in 1302c is t2 = (A + 4
00) + t3 = A + 400 + t3 = (A + t3) + 400, so if t1 = & A, there is no need to change statement 1302b, only statement 1302a and statement 1302c need to be updated. It will be good.

The result of the propagation is shown in 1303. In the sentence 1303c, the constant "400" appears in the expression for the operator "*".

FIG. 14 is a flowchart showing a process of updating a statement using the value of an external variable using the base variable in step 1005 of FIG.

Updating a statement using the value of an external variable is to propagate an integer constant appearing in the operator "&" due to the unification of the base variable into the operator "*" used when using the variable. It is.

First, the statement in the basic block is scanned to find the statement using the address of the external variable (step 140).
1). If this external variable is Y, the position is L from the external symbol table.
I understand Y.

Next, a base variable for this external variable Y is found in a base variable table (step 1402). This external variable is X. The position is LX.

If X and Y are equal, there is no need to perform base variable consolidation, so that it is checked in step 1403, and if X and Y are equal, in step 1410 it is checked whether or not the next external variable exists.

If X and Y are not equal, a process of scanning the intermediate code and updating the portion using the value of the variable Y to use the base variable X is performed.

First, one sentence in which the variable X is used is obtained from the external symbol table (step 1404). Here, processing depends on the type of sentence used.

(1) Addition and Subtraction In this case, it is possible to pass through as it is. In other words, it is sufficient to follow the usage of the variable on the left side of addition and subtraction (step 120
6).

(2) In the case of using the value of a variable (in the case of "*" operation) In this case, the result of adding the immediate part already appearing in the "*" operation and LY-LX is the instruction of the CPU. If the value is within the range of the immediate value that can be specified,
(LY-LX) (step 1209). If it exceeds the range, the base variable sharing for the external variable Y is abandoned, and the next external variable is searched for (step 1411).

(3) In Other Cases Since it is impossible to propagate an integer constant, the base variable sharing for the external variable Y is abandoned, and the next external variable is searched for (step 1411).

After performing the above processing, if there is a next sentence to be used (step 1409), the process returns to step 1404 to repeat the processing. If not, find the next external variable (step 1410) and repeat from step 1401.

FIG. 15 shows an intermediate code immediately after applying the load instruction update processing 1005 in the base variable common processing 220 to the intermediate code of FIG. 5 in order to show the effect of the base variable commonization according to the present invention. It is a thing.

The basic block 1501 corresponds to the basic block 502. In 502, address holding variables for three external variables A, B, and C are used. In 1501, address holding variables for only the external variable A are used. Basic block 1502 corresponds to basic block 504. In 504, an array element is referred to using the three address holding variables. In contrast, in 1502, only one address holding variable is used.

FIG. 16 shows an intermediate code when the useless code deletion processing 1006 in the base variable common processing 220 is applied to the intermediate code of FIG. 5 in order to show the effect of base variable commonization according to the present invention. It is a thing.

Since the variables t3 and t4 in the basic block 1502 are not referred to in the loop, deleting them does not affect the execution of the program. As a result of deleting the statements of t3 and t4 in 1502, 1502 changes like 1602. Furthermore, the variables t3 and t4 in the basic block 1501 are no longer referred to,
These can also be deleted. As a result of deleting t3 and t4 of 1501, 1501 changes like 1601.

As a result, four assignment statements and two variables have been deleted from the intermediate code shown in FIG. The number of statements executed for the intermediate code in FIG. 5 is 4 + 1 + 8 × 100 = 805
However, the number of statements executed for the intermediate code in FIG. 16 is 2 + 1 + 6 × 100 = 602. That is, about 25% (1-60
2/805) has been deleted. Also, two variables t3 and t4 have been deleted. Since one CPU register is assigned to one variable by the register assignment process, the number of registers can be reduced by two.

[0082]

According to the present invention, the number of load / store instructions involved in referring to different external variables is reduced, the number of executed instructions is reduced, and the execution speed is improved. Also, by reducing the number of registers of the CPU to be allocated to the external variables, the burden of other optimizations is reduced, the opportunities for optimization are increased, and the execution speed is improved.

[Brief description of the drawings]

FIG. 1 shows a method of indirectly referencing an external variable.

FIG. 2 shows a configuration of a compiler and a linker according to the present invention.

FIG. 3 shows an example of a source module using an external variable.

FIG. 4 shows a configuration of a compiler according to the present invention.

FIG. 5 shows an example of an intermediate code.

FIG. 6 shows the contents of a basic block. .

FIG. 7 shows an external symbol table in the module.

FIG. 8 shows a configuration of a linker according to the present invention.

FIG. 9 shows an external symbol table.

FIG. 10 is a flowchart showing a flow of a process of unifying base variables according to the present invention.

FIG. 11 shows a base variable table used in base variable unification.

FIG. 12 is a flowchart showing a base variable registration process.

FIG. 13 shows a change in intermediate code due to sharing of base variables.

FIG. 14 is a flowchart showing a variable use point updating process by base variable commonality.

FIG. 15 illustrates an example of an intermediate code immediately after a load instruction update process.

FIG. 16 shows an example of an intermediate code immediately after useless code deletion processing.

[Explanation of symbols]

201: source module, 204: compiler, 20
5 ... Syntax analysis step, 206 ... Compiler optimization step, 207 ... Intermediate code, 210 ... Module internal symbol table, 213 ... Library, 215 ... Linker, 216 ... External symbol table creation step, 217 ... External symbol table, 220 ... Base variable commonization step, 222
... Link step, 223 ... Load module, 10
04: a step of obtaining a base variable; 1005: a step of updating a load instruction; 1006: a step of deleting unnecessary code.

Claims (3)

[Claims] When a load module is generated by a linker, a step of reading an external symbol table and a library in a module generated by a compiler, a step of reading an intermediate code generated by a compiler, and scanning the intermediate code to perform optimization. Link optimization, comprising the steps of: generating a load module from an intermediate code and a library; and reducing the number of registers for referencing external variables in the step of performing the intermediate code optimization. Method. 2. The link optimization method according to claim 1, wherein in the step of optimizing the intermediate code, a base register is shared in order to reduce the number of registers used. Method. 3. A step of inputting a source file when generating an intermediate code by a compiler, a step of parsing the source file to generate an intermediate code, and a step of scanning the intermediate code to generate external variable information. Generating an intermediate code by optimizing the intermediate code, wherein the external variable information is generated to cause the linker to perform optimization based on the external variable information.