JP2834171B2 - コンパイル方法 - Google Patents

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は最適化機能を備えたコンパイラに係り、特に
プログラムの再コンパイル時における最適化処理の所要
時間短縮に好適なコンパイル方式に関する。

〔従来の技術〕

コンパイラにおける最適化機能とは、コンパイルに際
してプログラムに各種のプログラム変換（最適化処理）
を施すことにより、プログラムの実行を高速化する機能
である。

近年、スーパコンピユータ，並列コンピユータ等の出
現により、非常に大規模な科学技術計算を高速に実行す
ることが可能となつてきたが、これらスーパコンピユー
タ，並列コンピユータの性能を引き出すためには、コン
パイラの最適化機能が重要であり、プログラムの実行性
能は、コンパイラの最適化機能の能力に大きく依存す
る。そこで、近年、各社の間でコンパイラの最適化機能
の強化をめぐつた競合が激化している。

これに伴い、最適化処理が複雑化し、最適化処理の所
要時間が急激に増大しつつある。最適化処理の所要時間
は、従来からコンパイル時間の大きな比率を占めている
ため、最適化機能の強化に伴つて、コンパイル時間の増
大が大きな問題となつている。

従来、最適化処理時間の短縮のための方法としては、
各最適化処理自体のアルゴリズムの改良・処理削減等に
よる高速化以外方法がなかつた。

単にコンパイルの回数を減らすための方法としては、
分割コンパイルという手法がユーザによつて実施されて
いた。分割コンパイルとは、コンパイルの最少単位であ
る手続き（サブルーチン，関数等とも呼ばれる）をそれ
ぞれ独立にコンパイルし、それぞれの手続きのオブジエ
クトプログラムを別々に保持し、プログラムに修正があ
つた場合は、修正のあった手続きのみを再コンパイル
し、残りの手続きはオブジエクトプログラムを再利用す
るという手法である。

この分割コンパイルを行うためには、ユーザが再コン
パイルの度に、再コンパイルが必要な手続きを解析し、
それらの手続きのコンパイルをコンパイラに指示する必
要があつた。そこで、再コンパイルを自動化する技術
（自動再コンパイル）が開発された。この自動再コンパ
イルは、オブジエクトプログラムの作成以後にソースプ
ログラムが修正された手続きを検出し、該手続きを自動
的に再コンパイルするという技術である。この為に、各
手続きのソースプログラムの修正日時とオブジエクトプ
ログラムの作成日時の新旧を比較し、前者が後者よりも
新しい手続きは再コンパイル必要と判断する。

しかし、手続き間に跨った最適化である手続き間最適
化をコンパイラが実施した場合は、どの手続きに対して
再コンパイルが必要かをユーザが知ることはできない。
何故なら、手続き間に跨って最適化を行った場合は、プ
ログラムの修正の影響が最適化に関わつた複数の手続き
間に及ぶため、修正された手続きだけでなく未修正の手
続きも再コンパイルが必要となる為である。しかも、未
修正の手続きの再コンパイルの必要性は、コンパイラが
実施した手続き間最適化の内容に依存する。その為、ソ
ースプログラムの修正日時とオブジエクトプログラムの
作成日時のみから再コンパイルが必要な手続きを知るこ
とは出来ない。よつて、手続き間最適化が行われる場合
には、分割コンパイルは行われず、全ての手続きを再コ
ンパイルしていた。

これに対して、コンパイラ自体はどの様な手続き間最
適化が行われたかを知つているので、実施された手続き
間最適化についての情報を記録しておけば、手続き間最
適化が行われた場合でも再コンパイルを自動化すること
が可能である。該技術については、エー・シー・エム，
プロシーデイングズ オブ ザ シグプラン 86 シン
ポジウム オン コンパイラ コンストラクシヨン：シ
グプランノーテイシイズ，第21巻,7号（1986年７月）第
58頁から第67頁（ACM,Proceedings of the SIGPLAN 86
Symposium on Compiler Construction:SIGPLAN Notice
s,Vol.21,No.7（July 1986）PP58−67）に記載されてい
る。

該従来技術では、各手続きの最適化に際して、手続き
間データフロー情報のうち、該手続きに実施された最適
化を適用可能にするうえで必要だつた情報（手続き間デ
ータフロー条件）を記録しておく。再コンパイルに際し
ては、プログラムの修正に伴つて、別の従来技術により
手続き間データフロー情報を更新したのち、更新後の手
続き間データフロー情報に対して各手続きの手続き間デ
ータフロー条件が真かを判定する。これにより、前コン
パイル時に実施された最適化が更新後の手続き間データ
フロー情報に対しても適用可能か分かる。そこで、該手
続き間データフロー条件が真となつた手続きは、前コン
パイル時のオブジエクトプログラムを再利用し、偽とな
つた手続きは更新後の手続き間データフロー情報のもと
で再コンパイルする。

また、本特許に関連が深い従来技術としては、インク
リメタル・コンパイレーシヨンがある。インクリメタル
・コンパイレーシヨンとは、構文解析後のプログラムの
中間コードを保持しておき、プログラムの修正に伴つ
て、修正された部分のみを構文解析し直し、それ以外の
部分は中間コードを再利用することにより、構文解析の
処理量を削減する技術である。構文解析は、従来、局所
的な処理であるため、このように修正部分のみを再処理
するのは比較的容易である。

該インクリメタル・コンパイレーシヨンについては、
エー・シー・エム，プロシーデイングズ オブ ザ シ
グプラン 84 シンポジウム オン コンパイラ コン
ストラクシヨン：シグプラン ノーテイシイズ，第19
巻,6号（1984年６月）第122頁から第131頁（ACM,Procee
dings of the SIGPLAN 84 Symposium on Compiler Cons
truction:SIGPLAN Notices,Vol.19,No.6（June 1984）P
P122−131）に記載されている。

〔発明が解決しようとする課題〕

上記従来技術のうち、自動再コンパイルは、コンパイ
ル単位である手続きを単位として再コンパイルの必要性
を解析し、再コンパイルが不要な手続きの再コンパイル
を回避する技術である。その為、コンパイラが手続き間
最適化を行うかどうかに係わらず、修正された手続き自
体は必ず再コンパイル対象となり、また、再コンパイル
が必要であることが分かつた手続きに対しては、最適化
を全て初めからやり直すため、コンパイル処理時間の削
減効果は無い。

すなわち、自動再コンパイルは、再コンパイルすべき
手続きの決定を行うのみで、再コンパイルが決定した手
続きの最適化処理の削減には役立たない。そのため、修
正量が極めて僅かで、修正の影響が実際には少ない場合
でも、再コンパイル処理で多大な時間を要する場合があ
る。

従来技術のうち、インクリメタル・コンパイレーシヨ
ン技術は、修正を受けた部分に限定して構文解析を行う
技術である。しかし、インクリメタル・コンパイレーシ
ヨンの目的は、修正後のプログラムをなるべく早くコン
パイルし、実行・テストすることにより、デバツクを効
率よく行うことである。そこで、インクリメタル・コン
パイレーシヨンにおいては、最適化処理をほとんど行わ
ない。その為、大域的な処理が必要である最適化処理に
ついては全く考慮されておらず、コンパイル処理時間の
大部分を最適化処理に費やす最適化コンパイラにおいて
は、コンパイル処理時間の削減効果はほとんど無い。

本発明の目的は、再コンパイル対象となつた手続きの
コンパイルにおいて、前コンパイル時の結果をより有効
に利用することにより、該手続きのコンパイル時間を短
縮することである。

〔課題を解決するための手段〕

上記目的を達成するために、本発明のコンパイラにお
いて用いている手段を以下で説明する。

先ず、概要は次の通りである。

（１）手続きを幾つかに分割し、各分割単位（セグメン
ト）ごとに最適化を行い、再コンパイル時には、手続き
全体ではなく修正の影響を受けるセグメントのみを最適
化し直し、修正の影響を受けないセグメントは、前コン
パイル時の最適化結果を再利用する。

（２）最適化処理の幾つかの段階で、最適化の中間結果
を記録しておき、再コンパイル時には、修正の影響を受
けない段階までは、前コンパイル時の最適化の中間結果
を再利用する。

（３）最適化の中間結果だけでなく、実施された最適化
の内容も記録しておき、再コンパイル時には、前コンパ
イル時に実施された最適化のうち修正の影響を受けない
ものを選んでそのまま実施する。

以下で、本発明で用いている手段について、より詳細
に説明する。

第１に、ユーザがプログラムを機能的に分割した単位
である手続きは、最適化結果の再利用単位として必ずし
も適切ではないので、コンパイラが、プログラムを、最
適化結果の再利用に適切な単位（セグメント）に分割
し、各セグメント毎に最適化結果の再利用を図ると良
い。すなわち、次のようにすると良い。

1.（セグメント分割） プログラムのコンパイルに際して、コンパイラがプロ
グラムのコンパイル単位であるサブルーチン・関数（手
続き）を更に幾つかの分割単位（セグメント）に分割
し、構文解析直後の中間コード，セグメントの切り方を
示すセグメント管理情報を記録し、最適化においては各
セグメントごとにセグメント内のデータフロー情報のみ
を用いた最適化を行い、各セグメント毎の最適化後中間
コードを記録し、該手続きの再コンパイルにおいては、
ソースプログラムの修正に対応して中間コードとセグメ
ント管理情報を更新した後、修正を含むセグメント内で
のみ最適化を行い、修正を含まないセグメントでは、最
適化処理に代わつて前コンパイル時の最適化後中間コー
ドを再利用する。

上記では、各セグメント内においては、セグメント内
で閉じた最適化のみ行つたが、セグメント間に股がつた
データフロー情報（セグメント間データフロー情報）を
用いる場合は、最適化結果の再利用時に、セグメント間
データフロー情報についてのチエツクが必要である。そ
のために次のようにする。

2.（セグメント間データフロー情報の利用） １において、最適化に先立ち複数のセグメント間に跨
ったデータフロー解析も行い、各セグメント毎に最適化
においては、セグメント内のデータフロー情報だけでな
くセグメント間のデータフロー情報を用いた最適化も行
い、最適化語中間コードの記録に際しては、該最適化が
適用可能であるためのセグメント間データフロー情報に
ついての条件（セグメント間データフロー条件）も併せ
て記録し、再コンパイル時には、セグメント内に修正が
無いことに加えて該セグメントのセグメント間データフ
ロー条件が真のときに限り、該セグメントの最適後中間
コードを再利用する。

セグメント分割では、ある程度の大きさのプログラム
部分をセグメントとしてプログラムを分割するが、セグ
メントの選び方が悪いと最適化処理が十分に行われない
ので、セグメントは適切に選ぶ必要がある。効果が大き
い最適化はループを主な対象としている事に注目する
と、セグメント分割では、ループをなるべく分割しない
ようにすればよい。また、プログラムの修正によりセグ
メントの大きさが適正な範囲を越えた場合は、セグメン
トを再分割したり、他のセグメントと連結するなど、セ
グメントの大きさを適正に制御する必要がある。

以上をまとめると、次の3,4のようになる。

3.（ループを中心とした分割方法） １において、セグメントとして予め決められた大きさ
以下のプログラム部分を用い、かつ、大きさが予め決め
られた大きさ以下の最内側ループ又は最内側多重ループ
は該分割によつて分断されないようにする。

4.（セグメントの大きさの制御方法） １において、ソースプログラムの修正によりあるセグ
メントが予め決められた大きさより小さくなつた場合
は、該セグメントを他のセグメントと連結し、逆に、予
め決められた大きさより大きくなつた場合は、該セグメ
ントを更に分割し、セグメントの大きさを適正に制御す
る。

１から４では、最適化結果の再利用性を増すためにプ
ログラムを分割したが、別法として、最適化処理を時間
的に分割し、再利用の利く時点までの結果を再利用する
のも良い。

5.（最適化処理の分割） 最適化処理全体の流れを時間的に分割し、プログラム
のコンパイル単位である手続きのコンパイルに際し、分
割された処理のまとまり（処理群）ごとに最適化後中間
コード、該処理群内で実施された全ての最適化が適用可
能であるための手続き間データフロー情報についての条
件（手続き間データフロー条件）を記録し、既にコンパ
イルされた手続きの再コンパイルに際しては、該手続き
が未修正であれば、処理群の処理順に最適化後中間コー
ドの再利用性を判定し、該判定においては、ａ）該処理
群が先頭の処理群であるかまたは１つ前の処理群で最適
化後中間コードが再利用されていて、かつ、ｂ）該処理
群に対する手続き間データフロー条件が真かを判定し、
該再利用性判定が真なら該処理群に於ける最適化処理に
代わり、該処理群の最適化後中間コードを再利用する。

また、セグメント分割と最適化処理の分割を組み合わ
せると次のようになる。

6.（１〜４と５の組み合わせ） 最適化処理全体の流れを５の処理群に分割し、プログ
ラムのコンパイルに際しては、コンパイラがプログラム
のコンパイル単位である手続きを更に１のセグメントに
分割し、構文解析直後の中間コード、セグメントの切り
方を示すセグメント管理情報を記録し、最適化において
は、各処理群ごとに、各セグメントごとに、セグメント
内の最適化を行い、各セグメントの最適化後中間コード
と２に記載のセグメント間データフロー条件の記録を行
い、該手続きの再コンパイルにおいては、ソースプログ
ラムの修正に対応して中間コードとセグメント管理情報
を更新した後、処理群の処理順に、該手続きの各セグメ
ントごとに、最適化後中間コードの再利用性を判定し、
該判定においては、ａ）該処理群が先頭の処理群であつ
て該セグメント内に修正が無いかまたは１つ前の処理群
で該セグメントの最適化後中間コードが再利用されてい
て、かつ、ｂ）該セグメントのセグメント間データフロ
ー条件が真か判定し、該再利用性判定が真ならば、該処
理群の該セグメントに対する最適化処理に代わり、該処
理群の該セグメントの最適化後中間コードを再利用す
る。

また、以上のように最適化の結果を再利用するのでは
なく、最適化方法自体を再利用することも考えられる。
すなわち、実施された最適化の種別，対象や方法（プロ
グラム変換履歴）を記録しておき、再コンパイルに際し
ては、該プログラム変換が修正後のプログラムに適用で
きるか判断し、適用できるもののみ適用するという方法
である。この方法では、真に修正の影響を受けた最適化
以外は全て再適用可能なので、セグメント分割・最適化
処理分割に比べて前コンパイル時の最適化方法の再利用
性が高まる。

7.（プログラム変換履歴の記録と利用） コンパイル対象となつたプログラムに実施された各最
適化の個々のプログラム変換の実施ごとに、最適化の種
別とプログラム変換の変換対象と変換方法（併せて、プ
ログラム変換履歴と呼ぶ）を記録し、該プログラムの再
コンパイルに際しては、該プログラムのプログラム変換
履歴に記録された各プログラム変換に対して、記録され
た順番に、該プログラム変換がプログラムの意味を変え
ずに該プログラムの変換対象部分に再び適用できるかを
判定し、該判定が真ならば該プログラム変換を該プログ
ラムに適用する。

上記７で、修正後のプログラムに対するプログラム変
換の再適用性の判定のためには、該プログラム変換が適
用できる為の条件を生成し、これが真になるかを判定す
る必要がある。しかし、この条件は、前コンパイル時に
該プログラム変換を行うことを判断した時点で分かつて
いる情報である。そこで、この条件も再利用することが
できる。これをまとめると次のようになる。

8.（プログラム変換条件の記録と利用） ７において、前プログラム変換の再適用性判定手段と
して、プログラムのコンパイルに際して、該プログラム
に実施されたプログラム変換のプログラム変換履歴に加
え、該プログラム変換の適用を可能せしめた条件（プロ
グラム変換条件）を記録し、該プログラムの再コンパイ
ルに際しては、該プログラムのプログラム変換履歴に記
録された各プログラム変換に対して、該プログラム変換
のプログラム変換条件が該プログラムに対して真か判定
し、該判定の結果が真ならば、該プログラム変換が該プ
ログラムに再適用できると判定する。

また、最適化によつては、最適化の対象となる文と文
との間にプログラムの修正が無いという条件のみで、再
適用が可能なものもある。この様な場合、適用性の判定
が非常に容易であり、逆に、この様な最適化によるプロ
グラム変換のみを再利用するのであれば、データフロー
解析も不要となり、再コンパイル処理の削減処理は大き
い。これをまとめると、次のようになる。

9.（プログラム変換ドメインの記録と利用） ７において、前プログラム変換の再適用性判定手段と
して、プログラムのコンパイルに際して、該プログラム
に実施されたプログラム変換のプログラム変換履歴に加
え、プログラムの修正の影響が該プログラム変換の適用
性に直接及びプログラム部分の範囲（プログラム変換ド
メイン）を記録し、該プログラムの再コンパイルに際し
ては、該プログラムのプログラム変換履歴に記録された
各プログラム変換１に対するプログラム変換ドメインの
無修正条件の真偽を判定し、該無修正条件は、該プログ
ラム変換ドメイン内に前コンパイル時以降の修正が無
く、かつ、プログラム変換履歴に含まれたプログラム変
換のうち実施対象が該プログラム変換ドメイン内に含ま
れプログラム変換１よりも前に実施されたものは全て再
適用性判定が真であるという条件であり、該無修正条件
が真ならば、該プログラム変換が再適用可能と判定す
る。

上記９における無修正条件の判定のためには、中間コ
ードに修正有りマークを付け、次の10のようにする方法
が良い。

10.（無修正条件の判定方法） ７において、無修正条件の判定の為に、プログラムの
修正部分に対しては修正有りマークを付け、更に、無修
正条件が偽となつたプログラム変換においても該プログ
ラム変換の変換対象部分に修正有りマークを付け、無修
正条件の判定においては、プログラム変換ドメイン内に
修正有りマークが無い場合に該無修正条件が真と判定す
る。

更に、上記８記載のプログラム変換条件と上記９記載
のプログラム変換ドメインを組み合わせて利用すると、
より柔軟かつ最適な方法で再適用性判定の条件を表現す
ることができる。

11.（8.と9.の組み合わせ） ８において、プログラムに実施された各プログラム変
換のプログラム変換条件の一部の記録を省略し、代わり
に、プログラムの修正を行うと該省略した条件の真偽に
直接影響するプログラム部分の範囲を９に記載のプログ
ラム変換ドメインとして記録し、該プログラムの再コン
パイルにおける前プログラム変換の再適用性判定に際し
ては、該省略された条件の真偽判定に代わり、該プログ
ラム変換ドメインに対する９に記載の無修正条件の真偽
判定の結果を用いる。

さて、次に、プログラム変換履歴の記録・利用を処理
群ごとにまとめ、最適化結果のみ用いると、次の12のよ
うになる。

12.（最適化処理の分割とプログラム変換履歴の記録・
利用） 最適化処理全体の流れを５に記載の処理群に分割し、
プログラムのコンパイルに際しては、処理群ごとに、該
処理群で実施された全ての最適化のプログラム変換条件
を要約した条件（一括変換条件）と、全てのプログラム
変換ドメインを合わせたプログラム範囲（一括変ドメイ
ン）と、全てのプログラム変換の対象を合わせたプログ
ラム範囲（一括変換対象範囲）、および、該処理群の終
了時における一括変換対象範囲内の中間コード（最適化
後中間コード）を記録し、該プログラムの再コンパイル
に際しては、処理群の処理順に、該処理群の最適化後中
間コードの一括再利用性判定を行い、該一括再利用性判
定では、該一括変換ドメインに対する10に記載の無修正
条件が真で、かつ、該一括変換条件が真ならば、真と判
定し、該一括再利用性判定が真ならば、該一括変換対象
範囲において、該プログラムの中間コードを該最適化後
中間コードで置き換え、該一括再利用性判定が偽なら
ば、該一括変換対象範囲において全ての中間コードに修
正有りマークを付ける。

また、上記６（セグメント分割と最適化処理の分割）
とプログラム変換履歴の記録・利用を組み合わせ、セグ
メント毎の最適化結果が再利用できなかつた場合は、プ
ログラム変換履歴を利用すると、最適化処理の削減によ
り有効である。

13.（６と12のプログラム変換履歴の記録・利用の組み
合わせ） ６において、各処理群ごとの各セグメント内最適化に
際して、最適化後中間コードとセグメント間データフロ
ー条件に加えて、７に記載のプログラム変換履歴と８に
記載のプログラム変換条件と９に記載のプログラム変換
ドメイン（以上３つを併せて、プログラム変換情報と呼
び、最適化後中間コードとセグメント間データフロー条
件とプログラム変換情報とを併せて最適化情報と呼ぶ）
を記録し、該プログラムの再コンパイルにおける各処理
群ごとの各セグメント内最適化に際して、最適化後中間
コードの再利用性判定が偽の場合には、７から11までの
うちのいずれかの方法にしたがつて、プログラム変換情
報を用いた前プログラム変換の再適用を行う。

上記13では、セグメント間に跨った最適化は、セグメ
ント間データフロー情報を用いセグメント内でプログラ
ム変換を行うものに限られていたが、次のようにするこ
とにより、セグメント間に跨ったプログラム変換を伴う
最適化も扱えるようにすることができる。

14.（セグメント間プログラム変換） 13において、各処理群ごとに、全セグメントについて
セグメント内最適化を行つた後で、セグメント間に跨っ
た最適化を行い、該セグメント内最適化についての情報
を、７から12までのうちのいずれかの方法にしたがつて
記録・再利用する。

また、逆に、以下の15から18のように、ある処理群の
セグメント内最適化で用いるセグメント間データフロー
情報を限定することにより、記録する情報の減少、中間
コード一括再利用性判定の高速化等も行える。

15.（セグメント入口・出口情報への限定） 13において、ある処理群のセグメント内最適化で用い
るセグメント間データフロー情報を、該セグメントの入
口における定数伝播情報または出口におけるライブ変数
情報など、該セグメントの入口・出口におけるセグメン
ト間データフロー情報のみに限定する。

16.（呼び出し先手続きの手続き間情報のみへの限定） 13において、ある処理群のセグメント内最適化で用い
るセグメント間データフロー情報を、該セグメント内か
ら呼び出しされる呼び出し先手続きの手続き間情報のみ
に限定し、該セグメントのプログラム変換においては、
該手続きの呼び出しを跨いだプログラム変換、呼び出し
先手続きのインライン展開など、呼び出し先手続きの手
続き間情報を用いた最適化のみに限定する。

17.（フロー非依存な手続き間情報への限定） 16において、手続き間情報として、手続き内の制御フ
ローに依存せずにもとめられる手続き間情報のみに限定
し、各セグメントごとに該手続き間情報を保持し、該手
続き間情報の更新においては、修正された部分を含むセ
グメント内の解析のみを行い、該解析の結果と未修正の
セグメントの記録済み手続き間情報から該手続きの新し
い手続き間情報を求める。

18.（セグメント間情報の利用抑止） 13において、ある処理群のあるセグメント内の最適化
でセグメント間情報を利用する効果が少ない、又は、該
セグメントの実行比率が小さい場合は、該セグメント内
の最適化においてセグメント間情報を利用せず、セグメ
ント間データフロー条件の記録を省略し、再コンパイル
における該セグメントの最適化後中間コードの再利用性
判定に際しては、セグメント間データフロー条件の真偽
判定を省略する。

最後に、上記の各手段を組み合わせ、最適化レベル、
各最適化の平均的な処理量・効果・再適用性，ユーザの
指定，対象プログラムの平均的な修正量・修正の頻度・
影響範囲の尋さ，プログラムの各部分の実行時間・実行
比率，再適用されたプログラム変換の比率（最適化の効
果による重み付けを含む）によつて適切なコンパイル方
法を選ぶと、なるべく少ない情報の記録で最大の効果を
上げることができる。

19.（以上の組み合わせ） １から18およびこれらの組み合わせの中から、最適化
レベル、又は、各最適化の平均的な処理量・効果・再適
用性、又は、ユーザの指定、又は、対象プログラムの平
均的な修正量，修正の頻度・影響範囲の広さ、又は、プ
ログラムの各部分の実行時間・実行比率、又は、再適用
されたプログラム変換の比率（最適化の効果による重み
付けを含む）、およびこれらの組み合わせに従つて選択
したコンパイル方法でプログラムをコンパイルする。

〔作用〕

以上により、前コンパイル時の情報を有効に活用する
ことにより、再コンパイル時の最適化処理を削減する手
段を提供することができる。

〔実施例〕

以下、図面を参照しながら本発明の一実施例について
説明する。

第１図は本発明の一実施例の構成を示す。第１図にお
いて、１は再コンパイルか初コンパイルかを示すユーザ
指示、２はコンパイルすべき手続きのソースプログラ
ム、４は直前のコンパイル時以降のソースプログラム２
に対する修正内容を記述したプログラム修正情報、６は
コンパイラ、８はオブジエクトプログラム、10は実施さ
れたコンパイル処理についての記録であるコンパイル情
報であり再コンパイル時のコンパイル処理削減のために
記録・更新・利用する。

コンパイラ６は、入力として、ユーザ指示１とソース
プログラム２とプログラム修正情報４を与えられ、オブ
ジエクトプログラム８を出力する。ただし、初コンパイ
ル時は、ソースプログラム２のみ与え、再コンパイル時
は、プログラム修正情報４のみ与えるものとする。

また、コンパイラ６は、コンパイル処理に際してコン
パイル情報10の記録，更新および利用も行う。コンパイ
ル情報10は、コンパイラ６の起動・終了に依存せずに恒
久的に保持されるデータであり、初コンパイル時に記録
しておき、再コンパイル時に更新・利用する。また、コ
ンパイラ６は、コンパイル処理中のみ保持する一時的な
データであるセグメント間データフロー情報16とセグメ
ント内データフロー情報17の記録および利用も行う。

以下では、本発明の実施例の構成について第１図を用
いて説明するが、その前に、第2A図と第2B図を用いて本
実施例による最適化処理削減方法およびその効果につい
て概要を説明する。

第2A図は、本実施例における再コンパイル時の処理の
例である。先ず第１に、本実施例ではコンパイル時の最
適化処理を幾つかの処理群46に分けており、初コンパイ
ル時に各処理群46ごとにその処理群46の処理が終了した
時点で中間コード（最適化後中間コード30）が記録して
ある。再コンパイル時には、修正の影響を受けない処理
群の処理をしているあいだは、最適化処理に代わつてそ
の処理群に対する最適化後中間コード30を再利用するこ
とができる。図の中央はｉ番目の処理群46であり、右側
はそれに対応した最適化後中間コード30であり、左側は
ｉ−１番目の処理群46の最適化後中間コード30である。
処理群46では、再コンパイル時の更新後のｉ−１番目の
処理群46の最適化後中間コード30を入力して、ｉ番目の
処理群46の最適化後中間コード30を更新する。最適化後
中間コード30は、１つの手続きについての中間コードで
あつても幾つかの部分（セグメント）に分割されてお
り、各セグメントごとにプログラムの修正の影響に応じ
て別々の処理がなされる。

最適化処理および中間コードがそれぞれいくつかに分
割されているのは、共に、最適化後中間コード30の再利
用性を高めるためであり、コンパイル処理を大巾に削減
することができる。従来はこの様な分割を行つていない
ので、１つの手続き内に修正があるとその手続き全体に
ついて全ての最適化処理を再実施する必要があつたが、
この様に最適化処理を処理群46に分割し、中間コードを
セグメントに分割することにより、各セグメントごと
に、そのセグメントに対する最適化処理が修正の影響を
受けない処理群46のあいだは、そのセグメントの最適化
後中間コード30を再利用することができる。第2A図にお
いて、セグメント１とセグメント２とセグメント５は修
正の影響を受けないため、ｉ番めの処理群では、既に記
録されたｉ番目の最適化後中間コード30をそのまま再利
用することができ（最適化後中間コード再利用51）、実
際には何もする必要がない。その為、コンパイル処理が
大巾に削減される。また、セグメント３では、修正の影
響があるため、最適化後中間コード30をそのまま再利用
することはできないが、修正の影響が少ないので、別な
方法（前プログラム変換再適用60）で最適化処理を削減
することができる。前プログラム変換再適用60は、初コ
ンパイル時に実施された最適の処理内容を記録してお
き、再コンパイル時にこの記録に基づいて再適用可能な
最適化のみを再適用する処理であり、再適用性の判定の
みで最適化を適用できるので、最適化対象の検出や最適
化方法の決定処理が不要となり、最適化処理を全てやり
直すのに比べてコンパイル処理が削減される。

第2B図を用いて、前プログラム変換再適用60について
説明しよう。

522は初コンパイル時の最適化処理の例であり、524は
その最適化処理の内容を記述した情報であるプログラム
変換情報20の例であり、526はプログラム修正情報４の
例であり、528は再コンパイル時の処理（前プログラム
変換再適用60）の例である。初コンパイル時の最適化処
理522としては、２行めの文の不要コード削除、１行め
の代入文の３行めへのコピー伝播、４行めと５行めでの
式Ｕ＋Ｖの共通式削除が順に行われている。

ここでは、最適化の途中結果のみ示してあるが、実際
は、これらの最適化を行うためには、不要コード削除の
対象になる文の検出，コピー伝播のコピー元になる文・
コピー先になる式の検出、互いに共通式になる部分式の
検出などが必要である。これら、最適化対象の検出で
は、プログラム全体に渡つて総当たり的な探索が行われ
るので、処理量はかなり大きい。また、他の最適化、例
えば、インダクシヨン式リダクシヨン，ループ不変式移
動，ループ展開，インライン展開などでは、最適化の適
用方法が一通りのみではないので、最適化の適用方法も
決定しなければならない。一般に最適化処理は、最適化
対象の検出，最適化の適用方法の決定，中間コードの書
き替えの３段階に分けることができる。それぞれの処理
量は最適化の種類によつて異なるが、少なくとも、最適
化の適用方法の決定，中間コードの書き替えの処理量は
最適化処理の半分以上と思われる。また、最適化を強化
する場合、最適化対象をより一般化したり、最適化の適
用方法の種類を増やすなど、最適化対象の検出と最適化
の適用方法の決定の処理が増える場合が多い。前プログ
ラム変換再適用60は、この２つの処理を削減するのが目
的である。これらの処理を削減すると、コンパイル処理
の削減効果は大きい。

再コンパイル時の処理である前プログラム変換再適用
60では、修正後のプログラムに対して、これらの最適化
の再適用を図る。そのために、初コンパイル時にプログ
ラム変換情報20を記録する。再コンパイル時には、この
プログラム変換情報20に基づいて再適用可能な最適化の
みを、修正を含む中間コードに再適用する。プログラム
変換情報20の内容としては、524に示したように、最適
化の種別，最適化の対象，最適化の適用方法（合わせ
て、プログラム変換履歴28と呼ぶ），プログラム変換ド
メイン24（プログラムの範囲であつて、その範囲内でプ
ログラムが修正された場合に、その最適化に影響を与え
るもの），プログラム変換条件（その最適化を適用可能
としたデータフロー条件）が記録される。例えば、プロ
グラムの２行目に対する不要コード削除では、最適化種
別は不要コード削除であり、最適化対象は２行め全体で
あり、最適化方法は２行め全体を削除することであり、
プログラム変換ドメイン24は２行めであり、プログラム
変換条件26は「２行めの直後で変数ＢがLiveでないこ
と」である。プログラムの４行目と５行目の式Ｕ＋Ｖに
対する共通式削除では、最適化対象は４行めの部分式Ｕ
＋Ｖと５行めの部分式Ｕ＋Ｖであり、最適化の適用方法
は、「４行めの直前にＵ＋Ｖの計算コード（T1＝Ｕ＋
Ｖ）を挿入し、４行めと５行めで部分式Ｕ＋Ｖを変数T1
で置き換えること」であり、プログラム変換ドメイン24
は４行目から５行目であり、プログラム変換条件はな
い。次に、再コンパイル時に526のプログラム修正情報
４が与えられた場合の前プログラム変換再適用60の処理
例を528に示す。526のプログラム修正情報は、５行目の
直後に新しい行「Ｃ（Ｉ）＝Ｂ」を挿入することを示
す。528においては、挿入された行には修正があること
を示すマーク（Ｘ）を付けてある。前プログラム変換再
適用60は次のように行われる。２行めの文の不要コード
削除に対しては、６行めに変数Ｂの参照ができたことに
より、プログラム変換条件26が偽になるので再適用しな
い。これにより、２行めは削除されないので、初コンパ
イル時と異なつた中間コードになる。そこで、これを示
すため、最適化対象を含む行である２行めには修正マー
クを付ける。１行めの代入文の３行めへのコピー伝播で
は、プログラム変換ドメイン24（１行目から３行目まで
の範囲）内に直前の処理で修正マークを付けた行（２行
目）があるので、最適用しない。４行めと５行めでの式
Ｕ＋Ｖの共通式削除では、プログラム変換ドメイン24
（４行目から５行目までの範囲）内に修正がなく、プロ
グラム変換条件26も真となり（条件がない時は真である
として扱う）、再適用する。

このように、前プログラム変換再適用60では、前コン
パイル時に実施された最適化にたいして、順次、再適用
性を調べ、再適用可能なものを前コンパイル時と同じ適
用方法で実施する。その為、最適化対象の検出や最適化
方法の決定処理が不要となる。また、再適用性の判定
は、最適化対象の検出すなわちプログラム全体に跨った
最適化対象の探索などに比べて、比較的軽い負荷で出来
るので、最適化処理を全てやり直すのに比べてコンパイ
ル処理が削減される。なお、本例は、最適用性の判定の
仕組みを説明することを目的としたために、最適化の再
適用率は余り大きくなかつたが、通常は、もつと再適用
率が高い。それでも、修正の内容によっては、再適用率
が低くなり、出力されるオブジエクトプログラムの実行
性能が悪くなる場合があるので、その様な場合は、もう
一度最適化し直したほうが良い。第１図の61の条件判定
はそのための再適用率の判定である。以上で、本実施例
の概要の説明を終える。

本実施例では、最適化処理を処理群46に分割し、プロ
グラムをセグメントに分割し、最適化後中間コード30の
再利用を図るところと、プログラム変換情報20を記録・
利用して最適化の再適用を図るところが大まかな特徴で
ある。

次に、第１図内の詳細な構成を説明する。先ずその前
に、コンパイラ６内の各処理が初コンパイル時の処理
か、再コンパイル時の処理かを明らかにしておこう。コ
ンパイラ６内の処理39は再コンパイルかどうかの判定処
理であり、再コンパイルの場合は、以後、右側の処理41
以後の処理が順に実行され、再コンパイルでない場合、
すなわち、初コンパイルの場合は、以後、左側の処理40
以降の処理が順に実行される。

さて、以下、コンパイル情報10内の各情報とコンパイ
ラ６内の各処理の関係を述べながら各構成要素の内容を
説明する。

12は中間コード、40は初コンパイル時にソースプログ
ラム２から中間コード12を作成する処理である構文解
析、41は再コンパイル時にプログラム修正情報４にもと
づいて中間コード12の更新を行う処理である中間コード
更新である。

14は中間コード12の分割状況および各分割単位（セグ
メント）ごとの情報を保持するセグメント管理情報であ
り、42は初コンパイル時に中間コード12のセグメントへ
の分割を行いセグメント管理情報14を作成する処理であ
るセグメント分割、43は再コンパイル時に中間コード12
内の修正状況に対応してセグメント管理情報14の更新を
行う処理であるセグメント更新である。

16はセグメント間に跨ったデータフロー解析の結果で
あるセグメント間データフロー情報、44はセグメント間
に跨ったデータフロー解析およびセグメント間データフ
ロー情報16の作成を行う処理であるセグメント間データ
フロー解析である。

46は最適化処理を時間的に分割した単位である処理群
であり、最適化処理は処理群１から処理群ｎまでｎ個の
処理群に分かれている。18は各処理群46で実施された最
適化についての情報である最適化情報であり、各処理群
ごとに記録・更新・利用される。また、最適化情報18
は、初コンパイル時に作成され、再コンパイル時に更新
・利用される。

45,50,51,58,60,61は各処理群内の主要な処理であ
り、それぞれの処理対象は１つのセグメント内に限定さ
れている。また、32,30,20は各最適化情報18内の情報、
17はセグメント内に限定したデータフロー解析の結果で
あるセグメント内データフロー情報であり、これらの情
報は各セグメントごとに独立に記録・更新・利用ができ
るようになつている。

45はセグメント内に限定したデータフロー解析を行い
セグメント内データフロー情報17を作成する処理である
セグメント内データフロー解析、50はセグメント内に限
定した最適化を行い最適化情報18の記録を行う処理であ
るセグメント内最適化処理、30は最適化後の中間コード
である最適化後中間コード、32は各セグメント内の最適
化後中間コード30を再コンパイル時に再利用するための
条件であるセグメント間データフロー条件、20は各セグ
メント内の中間コードに対し実施された最適化で行われ
る各プログラム変換についての記録であるプログラム変
換情報、51は再コンパイル時に各セグメントに対して行
う処理を決定する条件判定、58は前コンパイル時の最適
化後中間コード30を再利用する処理である最適化後中間
コード再利用、60は前記コンパイル時のプログラム変換
情報20をもとに前コンパイル時のプログラム変換の再適
用を図る処理である前コンパイル変換再適用、61は前プ
ログラム変換再適用60で再適用が可能であつたプログラ
ム変換の比率に対する条件判定である。

以上処理群46内の処理において、各ｉ番めの処理群46
の入力となる中間コードは、ｉが１のときは中間コード
12であり、ｉが２以上のときはｉ−１番目の最適化情報
18内の最適化後中間コード30である。また、出力となる
中間コードはｉ番目の最適化情報18内の最適化後中間コ
ード30である。

47は最後の処理群46に対する最適化後中間コード30か
らオブジエクトプログラム８を生成する処理であるコー
ド生成である。

以上で、本実施例の各構成要素の内容の説明を終え
る。

さて、次に、各構成要素間の制御の流れおよびデータ
の流れを説明する。但し、処理群46に係わる部分以外は
構成要素の内容説明の際に既に説明したので、処理群46
内の構成要素間の制御の流れおよびデータの流れについ
て説明する。

まず、初コンパイル時の処理であるが、セグメント内
データフロー解析45とセグメント内最適化50を各セグメ
ントに対して行う。但し、これらの２つの処理の前後に
ある小さな○印およびこれらを結ぶ上向きの矢印は、こ
れら２つの処理を各セグメントに対して実施する為の繰
返しを表しており、以下でも同様の表現を用いる。

次に、再コンパイル時の処理であるが、小さな○印で
挾まれた部分の処理を各セグメントに対して行う。条件
判定51ではセグメント内でどの処理を行うかを決定す
る。その結果に応じて、最適化後中間コード再利用58、
または、前プログラム変換再適用60と再適用率について
の判定61、または、初コンパイル時と同じ処理（セグメ
ント内データフロー解析45とセグメント内最適化50）を
行う。また、再適用率の判定61において、プログラム変
換の再適用率が十分大きくないと判定された場合は、や
はり、初コンパイル時と同じ処理を行う。但し、図中で
破線の矢印で示されているのは、再コンパイル時に初コ
ンパイル時の処理と同じ処理を行うことを表しており、
以下でも同様の表現を用いる。

以上で、本実施例の構成図である第１図の説明を終え
る。

次に、本実施例の各構成要素の動作に付いて、フロー
チヤートを用いながら説明する。

第３図は中間コード更新41のフローチヤートである。
中間コード更新41では、プログラム修正情報４を入力し
て、（最適化前の）中間コード12を更新する。中間コー
ドの更新方法自体は、前に述べた通り、従来技術である
インクリメンタル・コンパイレーシヨンで実現されてい
る。本実施例では、とくに、付加的に行われる処理を中
心に中間コード更新41の動作を説明する。本実施例で
は、更新により修正があつた行に対しては、修正がある
ことを示すマーク（修正マーク70）を中間コードに付け
る。特に、修正により行が削除された場合は、その行の
中間コードを完全に削除してしまうのではなく、修正マ
ーク70が付いた空文（を表す中間コード）に置き換える
ことにより、修正があつたことが分かるようにする。ま
た、修正によりプログラムの制御の流れが変わつた場合
には、新たに生じた制御の流れの終点（GOTO文などの飛
び先の文）の中間コード12に修正マーク70を付ける。こ
れにより、ある最適化のプログラム変換ドメイン24の中
への飛び込みが新たに生じたとき、対応する最適化の再
適用を抑止する。例えば、第2B図のプログラム例で、他
のプログラム部分での修正により５行めの文への分岐が
新たに生じたとき、５行めの文の中間コードに修正マー
クを付ける。これにより、４行めと５行めのＵ＋Ｖの共
通式削除が抑止される。このように最適化を抑止しない
と、５行めへの飛び込みが発生したとき、共通式の値を
保持する変数T1に値が設定されずに５行めで使われるこ
とになり、プログラムが不正になる。

さて、それでは、順を追つて第３図の中間コード更新
41のフローチヤートを説明しよう。

ステツプ311では、修正情報内で使われている行番号
と中間コード12内の行番号の対応が取れるよう、予め中
間コード12内の行番号を更新する。行番号の更新は、前
回の再コンパイル時の修正に対応して行われる処理であ
り、削除されて空文になつた行を除いた残りの行に対し
て、行番号を順に付け直す。ステツプ312では、修正に
よる制御フローの変更が検出できるよう、中間コードの
更新を行う前に制御フロー解析を行う。ステツプ313で
は、プログラム修正情報４を１項目読み込む。プログラ
ム修正情報４は、前コンパイル時以降のソースプログラ
ム２の修正内容を記述した情報であり、第９図に示した
形式の情報が順に並んだものである。修正内容として
は、行の削除，行の追加，行の置き換えがあり、それぞ
れ、前コンパイル時のプログラム内の行番号を基準とし
て、ある範囲の行の削除，ある行の後への新しい行の追
加、ある範囲の行の新しい行での置き換えを記述してい
る。このプログラム修正情報４は、種々のソースプログ
ラム管理システムから得ることができる公知の情報であ
る。ソースプログラム管理システムとしては、例えば、
unixのSCCS等がある。ステツプ314では、修正の内容に
応じた分岐を行い、修正内容が行の削除のときはステツ
プ316へ分岐し、行の追加のときはステツプ320へ分岐
し、行の置き換えのときはステツプ326へ分岐する。ス
テツプ316では、修正によつて新たに加わる制御の流れ
の終点の行の中間コードに修正マークを付け、次に、ス
テツプ318では、削除部分の各行の中間コードを修正マ
ーク付きの空文で置き換える。ステツプ320では、プロ
グラム修正情報４に含まれている挿入部分のソースプロ
グラムを構文解析し、中間コードを作成し、ステツプ32
2では、修正によつて新たに加わる制御の流れの終点の
行の中間コードに修正マークを付け、ステツプ324で
は、さきほど構文解析してできた新しい中間コードを指
定された部分に挿入する。ステツプ326では、プログラ
ム修正情報４に含まれている置き換え部分のソースプロ
グラムを構文解析し、中間コードを作成し、ステツプ32
8では、修正によつて新たに加わる制御の流れの終点の
行の中間コードに修正マークを付け、ステツプ330で
は、置き換えられる部分の各行の中間コードを修正マー
ク付きの空文で置き換え、ステツプ332では、さきほど
構文解析してできた新しい中間コードを置き換えを指定
された部分の直後に挿入する。ステツプ334では、プロ
グラム修正情報４がまだ残つているかどうかによつて、
まだ残つている場合はステツプ313へ進み、そうでない
場合は処理を終了する。以上で、中間コード更新41の動
作の説明を終える。

次に、第4A図のフローチヤートを用いて、セグメント
分割42の動作を説明する。セグメント分割42は、初コン
パイル時の処理であり、中間コード12をある一定の大き
さ以内の部分（セグメント）の列に分割し、セグメント
への分割状況をセグメント管理情報14に記録する処理で
ある。分割に当たつては、プログラム内のループをなる
べく分断しないようにしている。この理由は、ループに
対する最適化、すなわち、ループ不変式移動やループ展
開は効果が大きく、セグメント分割によつてループが分
断されると、分断されたループに対してはこれらの最適
化が行われなくなる事により、最適化の効果が落ちるた
めである。

ステツプ342では、プログラムに含まれる各ループ内
の中間コードの量を計算し、ステツプ344では、ループ
内の中間コードの量がセグメントサイズ上限U1以下のル
ープにマーク付けを行う。

セグメントサイズ上限U1は、セグメント分割の際のセ
グメントサイズの上限値であり、10〜50行程度にすれ
ば、最内側ループが分割されることは余り無いので十分
であろう。それでも、セグメント分割によつて最適化の
効果が落ちてしまう場合は、セグメントサイズ上限U1の
値をユーザが指定できるようにしたり、ループ毎に分割
禁止の指示をユーザが指定できるようにするなどの対策
も考えられるが、本実施例ではこれらの対策は省略す
る。

ステツプ346では、セグメントの先頭の文を表すS1
に、プログラムの先頭の文を設定する。ステツプ348で
は、セグメントの最後の文の候補を表すS2を決定する。
S2としては、文S1から文S2までの中間コードの大きさが
セグメント上限U1以下でかつ最大となるものとする。ス
テツプ350では、文S2がマーク付けされたループ内にあ
るかを判定し、これが真のときはステツプ360へ進み、
偽のときはステツプ352へ進む。ステツプ352では、文S1
から文S2までの中間コードを１つのセグメントとするこ
とをセグメント管理情報14に記録する。セグメント管理
情報14の内容は、第10図に示した。詳細は後で説明す
る。但し、特に、セグメント管理情報14内の最適化状態
番号608としては、０を設定する。最適化状態番号608
は、セグメントの最適化の状態を表しており、値が１の
時は最適化済であることを表し、−１と０の時は未最適
化状態である事を表している。未最適化状態のときの値
として−１と０との違いは、次のようである。０の時
は、最初の処理群46から最適化をやり直す必要があるこ
とを示す。−１の時は、途中の処理群46で最適化の再適
用率が悪くなつたため、以後の処理群で最適化をやり直
す必要があり、次回の再コンパイルでは、最初の処理群
46から最適化をやり直す必要があることを示す。

ステツプ354では、S2がプログラムの最後の文かを判
定し、これが真のときはステツプ357へ進み、偽のとき
はステツプ356へ進む。ステツプ356では、S2の次の文を
S1として設定し、ステツプ348へ進んで処理を繰り返
す。ステツプ357では、各セグメントのセグメント入り
口とセグメント出口を解析してセグメント管理情報14に
記録する。セグメント入り口とは、他のセグメントから
の制御の飛び込みがある部分であり、セグメント出口と
は、他のセグメントへの制御の飛び出しがある部分であ
る。次に、ステツプ359ではセグメントサイズがU1以下
のループに付けたマークをクリアし、セグメント分割42
の処理を終える。

ステツプ360では、文S2を含むマーク付きループのう
ち最外側のものを捜し、これをｌ（エル）に設定する。
ステツプ362では、文S1からループｌ（エル）の直前の
文までを１つのセグメントとすることをセグメント管理
情報14に登録する。この際、セグメント管理情報14内の
最適化状態番号608としては、０を設定する。ステツプ3
64では、ループｌ（エル）の先頭の文をS1に設定し、ス
テツプ348に進んで、処理を繰り返す。

次に、第10図を用いて、セグメント分割42によつて作
られる情報であるところのセグメント管理情報14の内容
を説明する。第10図のうち、左の部分は、先頭セグメン
トのセグメント管理情報へのポインタ602および各セグ
メントのセグメント管理情報603であり、中央の部分
は、各セグメント入口の情報621、各セグメント出口の
情報627、および、各手続き呼び出しについての情報63
3、右の部分はセグメント間データフロー情報16であ
る。ただし、セグメント間データフロー情報16は、セグ
メント間データフロー解析44で作られる情報である。

各セグメントのセグメント管理情報603は、ポインタ6
20でつながつている。604は、セグメントの先頭の行の
中間コードへのポインタであり、606は、セグメントの
最後の行の中間コードへのポインタであり、608は前述
の最適化状態番号である。610は、セグメント内に修正
があるかを示すフラグであり、初コンパイル時はこのフ
ラグはクリアしておく。612はセグメント内の中間コー
ドのうち修正マークが付いているものの比率を示し、初
コンパイル時は０にしておく。614は、セグメント入口
情報の先頭のエントリ（621）へのポインタであり、616
は、セグメント出口情報の先頭のエントリ（627）への
ポインタである。618は、セグメント内の手続き呼び出
しについての情報の先頭のエントリ（633）へのポイン
タである。620は次のセグメントのセグメント管理情報
へのポインタである。

セグメント入口情報621は、セグメント入口の行の中
間コードへのポインタ（622）、このセグメント入口で
の定数伝播情報の先頭（643）へのポインタ（624）、次
のセグメント入口のセグメント入口情報へのポインタ
（626）より成る。ただし、ポインタ624の値はセグメン
ト間データフロー解析44で設定される。

セグメント出口情報627は、セグメント出口の行の中
間コードへのポインタ（628）、このセグメント出口で
のLive変数情報の先頭（649）へのポインタ（630）、次
のセグメント出口のセグメント出口情報へのポインタ
（632）より成る。ただし、ポインタ630の値はセグメン
ト間データフロー解析44で設定される。

セグメント内の手続き呼び出しについての情報（63
3）は、手続き呼び出しを含む行の中間コードへのポイ
ンタ（634）、呼び出し手続き名（636）、この手続き呼
び出しに対する２つの手続き間データフロー情報へのポ
インタ（638と640）、次の手続き呼び出しについての情
報へのポインタ（642）よりなる。ただし、ポインタ63
8,640の値はセグメント間データフロー解析44で設定さ
れる。

次に、第12A図のプログラムを例として、セグメント
分割42が実施されたときのセグメントの分割例およびセ
グメント管理情報14を第12B図および第13図に示す。

第12A図は、入力となるソースプログラム２の例であ
る。FORTRAN言語で書かれており、SUB1という名前のサ
ブルーチンのソースプログラム２である。99はソースプ
ログラムの行に順に付けられた行番号である。ループ
は、４行目から22行目（ループDO10）、23行目から28行
目（ループDO60）が最外側ループであり、ループDO10は
内側に、８行目から10行目のループDO20、14行目から16
行目のループDO30、17行目から21行目のループDO40、18
行目から20行目のループDO50を含んでいる。

第12B図は、第12A図のソースプログラムの中間コード
12であり、理解し易くするため、ソースプログラムに近
い形式で表現してある。中間コード12内で、［と］で囲
まれた部分は、配列のアドレス計算式であり、ソースプ
ログラム２との違いは、主にこの部分である。

ただし、１行目から３行目は宣言部であり、セグメン
ト分割は行わないので、中間コードは書かなかつた。宣
言部は、修正の影響が中間コード全体に及ぶため、修正
された場合は、実行部の中間コード全体を最適化し直す
必要がある。これを避けるためには、中間コード更新41
において、宣言の内容が変更された変数・配列を参照す
る行に修正マークを付ければよく、容易に対処可能であ
り、本実施例では、宣言部の扱いは省略する。また、セ
グメントの大きさとしては、10〜50行程度は必要と思わ
れるが、この例では、セグメントの分割が分かりやすい
ように、セグメントサイズ上限U1は８行であるとした。
よつて、ループDO10以外は１つのセグメントに入れるこ
とができ、マーク付けされる。逆に、ループDO10はマー
ク付けされず、分割されることになる。

セグメント分割42の処理で最初に登録されるセグメン
ト（セグメント１）は行４から行11までの８行である。
このセグメントの最後の行はマーク付けされたループ内
でないので、そのままセグメントになる。次は、行12か
ら行19までの８行がセグメントの候補になるが、行19は
マーク付けされたループDO50内にあるので、そのままで
はセグメントにならず、行19を囲むマーク付きループの
うち最外側であるループDO40の直前（行16）までが、セ
グメント（セグメント２）になる。これによつて、１つ
のセグメントに入る大きさのループであるループDO40が
分断されずに済んだ。次は、行17から行24の８行がセグ
メントの候補になるが、行24はマーク付けされたループ
DO60内にあるので、そのままではセグメントにならず、
ループDO60の直前（行22）までが、セグメント（セグメ
ント３）になる、最後に、残つた部分がセグメント４に
なる。

第13図は、上記のセグメント分割に対するセグメント
管理情報14であり、セグメント１に対する情報のみを示
した。セグメント１に対するセグメント管理情報603の
うち、604には、セグメントの先頭である４行目の中間
コードへのポインダが入り、606には、セグメントの最
後である11行目の中間コードへのポインタが入る。608,
610,611には、初コンパイル時の値である０、偽、０が
それぞれ入る。

614はセグメント入り口情報の先頭621へのポインタが
入る。621Xと621Aはセグメント入口情報であり、それぞ
れ、４行めのセグメント入口と、５行目のセグメント入
口についての情報が入る。４行目はサブルーチンの実行
部の先頭であるが、サブルーチンは一般に複数回呼ばれ
るため、サブルーチンの最後の行から先頭の行への間接
的な制御の流れがあると考え、セグメント入口になる。
また、５行めは、ループDO10の繰り返し処理の際に、ル
ープ最後の行である22行めからの制御の流れがあり、セ
グメント入口になる。

616はセグメント出口情報の先頭627Xへのポインタが
入る。セグメント１では、11行めがセグメント出口であ
る。

618はセグメント内の手続き呼び出しについての情報
の先頭633Xへのポインタが入る。セグメント１では、７
行めに関数FNの呼び出しがあり、それに対応した情報が
633に設定されている。

以上で、セグメント分割42の処理の説明を終える。

次に、第4B図のフローチヤートを用いて、セグメント
更新43の動作を説明する。セグメント更新43は再コンパ
イル時の処理であり、中間コード12の修正に応じて、セ
グメント管理情報14の更新を行う。セグメント更新43で
は、各セグメントの最適化状態番号608を更新して、更
コンパイル時に初めから最適化し直すかを決めるととも
に、修正によりセグメントサイズが小さくなり過ぎたセ
グメントは他のセグメントと連結し、セグメントサイズ
が大きくなり過ぎたセグメントは分割するなどして、セ
グメントサイズを適性に保つ。セグメント更新43では、
セグメント管理情報14の更新が主な処理であるが、これ
に伴つて、中間コード12の修正マークも変える場合があ
る。詳細な、以下で説明する。

ステツプ371では、セグメント管理情報14と中間コー
ド12を参照して、既存のセグメント内でなく、セグメン
トとセグメントの間に挿入された中間コードを検出し、
それぞれの挿入部分の中間コードを新たなセグメントと
してセグメント管理情報14に登録する。これに際して、
最適化状態番号608としては、−１を設定し、初めから
最適化し直す必要があることを示す。

ステツプ372からステツプ376は、全てのセグメントに
ついて処理するために繰り返す部分であり、各セグメン
トについて、ステツプ372からステツプ376の処理が実施
される。ステツプ372では、処理対象のセグメントの最
適化状態番号608の値によつて分岐する。最適化状態番
号608の値が−１の時はステツプ373へ分岐し、０の時は
ステツプ375へ分岐し、１の時は376へ分岐する。ステツ
プ373では、セグメントの最適化状態番号608を０にし、
初めから最適化し直す必要があることを示し、次に、ス
テツプ374では、セグメント内の全ての中間コード12に
修正マークを付ける。中間コード12に修正マークを付け
るのは、このセグメントが他のセグメントと連結された
場合に、セグメント内修正比率612が正しく計算できる
ようにするためであり、セグメント内修正比率612の計
算を工夫すれば、ここで中間コード12に修正マークを付
けなくともよい。ステツプ375では、セグメントの最適
化状態番号608を１にし、最適化処理を行うのに代わつ
て、最適化情報18を再利用することを示す。ステツプ37
6では、セグメント内の中間コード中に修正マークの付
いたものがあるか、および、修正マークの付いた中間コ
ードの比率をセグメント管理情報14の610と612に設定す
る。また、修正マークの付いた中間コードの比率が大き
く、予め定めた上限値を越える場合は、最適化状態番号
608を０にして、初めから最適化し直す必要があること
を示す。

ステツプ377では、セグメントサイズが下限Ｌよりも
小さいセグメントを、直前又は直後のセグメントに連結
する。セグメントサイズの下限Ｌは、予め定められた値
である。また、連結先のセグメントとしては、直前又は
直後の２通りであるが、なるべく修正比率が大きく、セ
グメントサイズが小さいものを選ぶ。連結後のセグメン
トの最適化状態番号608は、連結先のセグメントの最適
化状態番号608が１で、かつ、連結後のセグメントの修
正比率が十分小さければ１にし、連結先のセグメントの
最適化情報18を再利用するが、それ以外の場合は０にし
て、初めから最適化し直す必要があることを示す。

ステツプ378では、セグメントサイズが上限U2よりも
大きいセグメントを分割する。すなわち、その様なセグ
メントの中間コード12をセグメントサイズがU1以下の複
数のセグメントに分割する。分割の仕方は、セグメント
分割42と同様であり、分割対象の中間コード12が手続き
の中間コード全体でないところが異なる。分割によつて
できたセグメントは最適化状態番号608を０にしてセグ
メント管理情報12に登録する。

ステツプ379では、最適化状態番号608が０のセグメン
ト内の全ての中間コードから修正マークを除去する。

ステツプ380では、セグメントの入口と出口を再解析
し、セグメント管理情報14内の対応する情報を更新す
る。

セグメント分割42およびセグメント更新43では、セグ
メントサイズの上限としてU1とU2を、セグメントサイズ
の下限としてＬを使う。セグメントサイズ上限U1は、セ
グメントサイズの初期上限値であり、セグメントサイズ
上限U2は、セグメントサイズ上限U1に、修正によつて増
えてもよい分を加えた上限値である。最適化情報18を有
効に活用するためには、これらの間には、次のように関
係が成り立つべきである。

Ｌ≪U1＜U1＋αＬ＜U2 ただし、αは最適化情報18の再利用を図りたいおおよ
その回数であり、２〜10程度 以上で、第4B図のセグメント更新43のフローチヤート
の説明を終える。

次に、これまでに説明した再コンパイル時の処理であ
る。中間コード更新41およびセグメント更新の適用例
を、第12A図のプログラムを例として説明する。修正情
報４としては、第18A図の情報が与えられたものとす
る。

第18A図の修正情報４は、５行目の次にIF分を１つ挿
入し、22行目の次に、W1への代入分を挿入し、24行目を
削除し、27行目を別の代入文で置き換えると言う修正を
示している。再コンパイル時の処理である中間コード更
新41によつて、中間コード12は第19図のように更新され
る。

第19図において、70は修正マークの欄であり、この欄
にＸと言う印が付いた行は、修正マークが付いているこ
とを示す。修正マークが付いている行は、行５の直後に
挿入された行、この行の挿入によつて新しく加わつた制
御フローの終点となつた行７、行22の次に新しく挿入さ
れた行、削除されて空文になつた行24、置き換えによつ
て空文になつた行および挿入された行の６カ所である。

セグメントの分割の仕方は、初コンパイル時（第12B
図）と余り変わらない。但し、行22の次に挿入された行
は、セグメント３とセグメント４の間に挿入された部分
であるが、セグメント４に連結されている。この理由
は、セグメント４の方が中間コードの修正比率612が大
きいためである。また、各セグメントの最適化状態番号
608は、セグメント１からセグメント３では１になり、
最適化情報18の再利用を図るが、セグメント４では修正
量が大きいため０になり、初めから最適化し直すことに
なる。

次に、第５図を用いて、セグメント間データフロー解
析44の処理の流れを説明する。セグメント間データフロ
ー解析44は、中間コード12を元に、セグメント間に跨っ
たデータフロー解析を行い、その結果をセグメント間デ
ータフロー情報16に設定する処理であり、初コンパイル
時も再コンパイル時も実施される。セグメント間データ
フロー情報16は、第10図の右側に示した情報である。す
なわち、セグメント入口で定数値を持つ変数の名前644
およびその値646、セグメント出口でLiveでありかつセ
グメント内に定義がある変数の名前650、手続き呼び出
しにおいて値が変更される可能性のある変数の名前65
6、手続き呼び出しにおいて値が使用される可能性のあ
る変数の名前660より成る。各情報は、まとめて、それ
ぞれ、定数伝播情報,Live変数情報,MOD情報,USE情報と
呼ばれる。

ステツプ381では、手続き間データフロー情報15（MOD
情報655,USE情報659）を各手続き呼び出し点の情報633
に設定する。但し、設定される情報は、セグメント間デ
ータフロー情報17の一部として設定される。また、手続
き間データフロー情報15の解析方法は公知なので、再コ
ンパイルが始まる前に既に更新済みであるものとする。

ステツプ382では、セグメント間Live変数解析を行
う。（実際にはセグメントを無視して、手続き全体にわ
たるLive変数解析を行えばよい） ステツプ384では、各セグメントの各セグメント出口
に対して、Liveかつセグメント内に定義がある変数の名
前650を、セグメント間データフロー情報16内に記録す
る。

ステツプ386では、セグメント間定数伝播解析を行
う。（実際にはセグメントを無視して、手続き全体にわ
たる定数伝播解析を行えばよい。この際、手続き間デー
タフロー情報15内にある手続き間定数伝播情報も用い
る） ステツプ388では、各セグメントの各セグメント入口
に対して、定数値を持つ変数の名前644のその値646を、
セグメント間データフロー情報16内に記録する。

第13図の右側に、第12A図のプログラムの初コンパイ
ル時のセグメント１のセグメント間データフロー情報16
の例を示す。但し、初コンパイル時の手続き間データフ
ロー情報15は第18B図の左側に示したようになつている
ものとする。第13図の右側に示したセグメント間データ
フロー情報16のうち、定数伝播情報（643,643A,643B）
と、手続き呼び出し点の情報（659,659A,659B）は、第1
8B図の左側の手続き間データフロー情報15に直接対応し
たものになつている。Live変数情報は、セグメント１の
出口でLiveである変数の名前K,E,F,G,T,K1が設定されて
いる。

以上で、処理群46以外の動作の説明を終える。

以下では、処理群46内の処理の詳細を説明する。処理
群46内の処理の概要については、第１図を用いて概要は
説明した通りであり、初コンパイル時は、セグメント毎
にセグメント内データフロー解析45とセグメント内最適
化50を行い、最適化情報18を作成し、再コンパイル時
は、条件判定51の結果に従って最適化後中間コード再利
用58、または、前プログラム変換再適用60、または、初
コンパイル時と同じ処理であるセグメント内データフロ
ー解析45とセグメント内最適化50を行う。最適化後中間
コード再利用58では、前コンパイル時の最適化後中間コ
ード30を再利用するので、セグメント内データフロー解
析45とセグメント内最適化50の処理が不要になり、コン
パイル処理が大巾に削減される。前プログラム変換再適
用60では、セグメント内最適化45において必要であつた
最適化対象の検出や最適化方法の決定が不要となり、前
コンパイル時に実施した最適化が再適用できるかを判定
するだけで済むので、コンパイル処理が削減される。但
し、前プログラム変換再適用60では、再適用される最適
化が少ない場合は生成されるオブジエクトプログラム８
の実行性能が大きく低下する可能性があるので、最適化
の再適用率が大きいか判定して（61）、十分に再適用さ
れてない場合は、初コンパイル時と同じ処理を再実施す
るようにしている。以上が、処理群46内の処理の概要で
あつた。

次に、処理群46のより詳細なフローチヤートである第
６図を用いて処理群内の動作をより詳しく説明する。

第６図は、ｉ番めの処理群46のフローチヤートであ
り、左側のフローチヤート392,45,50,394は、処理群46
内の処理のうち、初コンパイル時に各セグメントに対し
て行われる処理をより詳細化したものである。また、右
側のフローチヤート401,402,404,406,412,408,410,58,6
0,61,414,416は、処理群46内の処理のうち、再コンパイ
ル時に各セグメントに対して行われる処理をより詳細化
したものである。第６図には、それ以外に、これらのｉ
番めの処理群46で使われるデータも書かれている。14は
セグメント管理情報であり、入力となり、更新もされ
る。16はセグメント間データフロー情報であり、入力と
なる。390は処理群の入力となる中間コードであり、先
頭の処理群（ｉが１のとき）では（最適化前の）中間コ
ード12、それ以外（ｉが１以外のとき）では直前の処理
群46の最適化後中間コード30であり、入力となる。18は
ｉ番めの処理群46の最適化情報であり、そのうち、32は
セグメント間データフロー条件、20はプログラム変換情
報、30は最適化後中間コードであり、それぞれ、記録・
利用・更新される。（最適化情報の内容は後で詳しく述
べる） まずは、初コンパイル時の各セグメントに対する処理
から説明する。

ステツプ392では、処理中のセグメントに対する入力
中間コード390をメモリ上に読み込む。ステツプ45では
セグメント内データフロー解析を行う。（ただし、図が
繁雑になるので、出力となるセグメント内データフロー
情報17は省略した） ステツプ50では、セグメント内最適化を行い、メモリ
上の中間コードを書き替えると共に、セグメント間デー
タフロー条件32とプログラム変換情報20を生成して記録
する。（セグメント内最適化50のより詳細な処理は、後
でより詳しく説明する） ステツプ394では、処理中のセグメントに対するメモ
リ内の中間コードを最適化後中間コード30に書き込む。

以上により、処理中のセグメント内の中間コードに対
してセグメント内最適化50が行われると共に、このセグ
メントに対する最適化情報18（セグメント間データフロ
ー条件32とプログラム変換情報20と最適化後中間コード
30）が生成・記録される。

次に、再コンパイル時の各セグメントに対する処理を
説明する。

まず、ステツプ401,402,404,406は第１図の条件判定5
1をより詳細化したものである。ステツプ401では、セグ
メントの最適化状態番号608が１か、すなわち、前コン
パイル時に最適化が済んでいるかを判定し、これが真の
ときはステツプ402へ進み、偽のときは、初コンパイル
時と同じ処理であるステップ392,45,50,394を行う。ス
テツプ402では、セグメントの修正有りフラグ610が真か
を判定し、そうならばステツプ406へ進み、偽ならばス
テツプ404へ進む。ステツプ404では、処理中のセグメン
トのセグメント間データフロー条件32がセグメント間デ
ータフロー情報16に対して真になるか判定し、真なら
ば、ステツプ58へ進み最適化後中間コード再利用を行
い、偽ならばステツプ406へ進む。ステツプ406では、セ
グメントの修正比率612が小さいか判定し、真ならばス
テツプ408へ進んだのちプログラム変換再適用60を行
い、偽ならば、ステツプ412へ進んでこのセグメントの
最適化状態番号を−１に設定した後、初コンパイル時と
同じ処理であるステツプ392,45,50,394を行う。ステツ
プ412でセグメントの最適化状態番号608を−１に設定す
るのは、このセグメントに対して、以下の処理群46で初
コンパイル時の処理を行い、次回のコンパイル時には初
めから最適化し直すことを指示する為である。これによ
り、このセグメントに対するオブジエクトプログラム８
の実行性能が余り低下しないようにしている。

以上、条件判定51の処理により、最適化後中間コード
再利用58、又は、前プログラム変換再適用60、又は、初
コンパイル時の処理ヘ分岐する。なお、ステツプ406で
の判定で修正比率が小さいかどうかの基準は本実施例で
は特に定めないが、10〜20％程度の修正ならば、修正比
率が小さいと考えて良いだろう。また、修正の量だけで
なく、修正した部分が、局所的に狭いところにあるか、
広域的に分布しているかなども考慮し、修正が広域的な
場合は修正量が大きいものとして扱うなどの処理をする
と、より適切な判断ができると思われるが、詳細は省略
する。

ステツプ58では、最適化後中間コード再利用をおこな
う。すなわち、処理中のセグメントに対して前コンパイ
ル時のｉ番めの処理群46で記録・更新された最適化後中
間コード30をそのまま用い、実際は何の処理も行わな
い。この場合、コンパイル処理が大巾に削減される。

ステツプ408では、処理中のセグメントに対する入力
中間コード390をメモリ上に読み込み。

ステツプ410では、セグメントの修正有りフラグ610を
立てる。

ステツプ60では、前コンパイル時に記録・更新された
プログラム変換情報20を用いて、メモリ上の中間コード
に対して前プログラム変換再適用を行う。（前プログラ
ム変換再適用60の詳細は後で述べる。） ステツプ61では、前プログラム変換再適用60で再適用
された最適化の個数の比率が十分大きいか判定し、これ
が真ならば、ステツプ414へ進み、偽ならば、ステツプ4
12へ進んでこのセグメントの最適化状態番号を−１に設
定した後、初コンパイル時と同じ処理であるステップ39
2、45,50,394を行う。

なお、ステツプ61での最適化の再適用比率の判定基準
は本実施例では特に定めないが、80〜90％以上は必要と
思われる。また、単に再適用された最適化の個数の比率
で判断するのではなく、各最適化によるオブジエクトプ
ログラムの実行時間の削減効果も考慮して重み付けした
り、これを処理群ごとに累積していき、再適用されなか
つた最適化のオブジエクトプログラムの実行性能への影
響をより正確に予測するなどするとより適切な判断が行
えるが、詳細は省略する。

ステツプ414では、このセグメントに対するメモリ内
の中間コードを最適化後中間コード30に書き込む。

ステツプ416では、前プログラム変換再適用60によつ
て修正マーク付きの中間コードが増えたことに対応し
て、中間コードの修正比率612を更新する。

以上で、処理群46のより詳細なフローチヤート第６図
の説明を終え。次に、第６図内のセグメント内最適化50
と前プログラム変換再適用60の処理をより詳しく説明す
るために、これらの部分をより詳細化した第７図を用い
て説明する。

第７図において、左側のフローチヤートは処理群46内
の初コンパイル時の処理のうちセグメント内最適化50の
部分を詳細化したものであり、右側のフローチヤートは
処理群46内の再コンパイル時の処理のうち前プログラム
変換再適用60の部分を詳細化したものである。また、本
図では、プログラム変換情報20もより詳細に記載してあ
る。（ただし、プログラム変換情報20の具体的な内容に
ついては後で説明する） 先ずは、初コンパイル時の処理を説明する。

ステツプ45では、前述のようにセグメント内データフ
ロー解析を行い、結果をセグメント内データフロー情報
17に記録する。

次の処理50はセグメント内最適化であり、セグメント
内最適化50は、各１種類の最適化の適用（421）ごとに
分かれている。各１種類の最適化とは、例えば、コピー
伝播，共通式削除，ループ不変式削除などのことであ
る。各１種類の最適化の適用421では、ステツプ422〜42
5の処理が繰り返し行われる。

ステツプ422では、最適化が適用可能な中間コード
（最適化対象）の検出を行う。すなわち、メモリ上にあ
るセグメント内の中間コードを探索し、セグメント内デ
ータフロー情報17とセグメント間データフロー情報16も
用いて、最適化の対象となる中間コードの部分を検出す
る。

ステツプ423では、最適化対象が見付かつたかどうか
に従つて、見付かつたときはステツプ424へ進み、見付
からないときは、次の種類の最適化の適用421に移る。

ステツプ424では、ステツプ422で見付かつた最適化対
象に対して、最適化の適用方法を決定する。最適化の適
用方法の決定に当たつては、最適化対象の近辺の中間コ
ード，セグメント内データフロー情報17,セグメント間
データフロー情報16を基にして、最も適切な最適化適用
方法を選ぶ。

ステツプ425では、実際に中間コードの書き替え（プ
ログラム変換）を実施し、その内容を記録する。すなわ
ち、プログラムの修正を行つた場合そのプログラム変換
が再適用出来なくなる可能性のあるプログラム範囲をプ
ログラム変換ドメイン24に記録し、そのプログラム変換
を適用可能としたデータフロー情報についての条件をプ
ログラム変換条件26に記録し、プログラム変換条件26の
中でセグメント間データフロー情報に関する条件をセグ
メント間データフロー条件32に記録し、最適化の種類・
対象・適用方法をプログラム変換履歴28に記録する。そ
の後、422に制御を戻して処理を繰り返す。

以上により、セグメント内最適化処理50により、メモ
リ内にあるセグメント内の中間コードに対して最適化が
行われ、実施された最適化についての情報が、プログラ
ム変換ドメイン24,プログラム変換条件26,プログラム変
換履歴28、および、セグメント間データフロー条件32に
記録される。

次に、再コンパイル時の処理である前プログラム変換
再適用60の処理内容を説明する。

ステツプ432では、セグメント内データフロー解析を
行い、後は、このセグメントに対するプログラム変換履
歴28に記録された各プログラム変換に対してステツプ43
4からステツプ440の処理を行う。

ステツプ434では、処理中のプログラム変換のプログ
ラム変換ドメイン24内に修正マーク70付きの中間コード
があるか判定し、これが真のときは、ステツプ440に進
み、偽のときは、ステツプ436に進む。なお、この判定
のためには、プログラム変換ドメイン24内の全ての行の
中間コードに対して、修正マークがあるか調べる必要が
あるが、修正マーク70の有無の判定はほとんど処理を必
要としないし、セグメント内の行の数は余り多くないの
で、処理量は少ない。それでも、必要ならば、各行の中
間コードに修正マーク70を付けるだけでなく、これを含
む行の集まりである基本ブロツクにも修正マークを付け
るなどすると、より処理量を減らすことができるが、詳
細は省略する。

ステツプ436では、処理中のプログラム変換のプログ
ラム変換条件26が、現在のデータフロー情報（セグメン
ト内データフロー情報17とセグメント間データフロー情
報16）に対して真となるか判定し、これが真ならば、ス
テツプ438へ進み、偽ならば、ステツプ440へ進む。

ステツプ438では、このプログラム変換をメモリ内の
中間コードに対して実施し、この中間コードを書き替え
る。

ステツプ440では、メモリ上にある中間コードのうち
プログラム変換対象を含む行の中間コードに修正有りマ
ーク70を付ける。

以上により、プログラム変換履歴28に記録されたプロ
グラム変換のうち再適用可能なものは再適用され、再適
用不要なものはプログラム変換対象を含む行の中間コー
ドに修正有りマーク70が付けられる。

以上で、第７図の説明を終え、第６図の説明と合わせ
て、処理群46内の処理の流れの説明を終える。

次に、第11A図と、第11B図を用いて、処理群46内の処
理で記録・更新・利用されるデータである最適化情報18
の内容を説明する。

第11A図は、最適化情報18の構造を示した図であり、
第11B図はその中でプログラム変換情報20の構造を示し
た図である。

まず、第11A図から説明する。最適化情報18は、最初
の処理群46の最適化情報703へのポインタ702を通して参
照され、最初の処理群46の最適化情報703は、先頭セグ
メントの最適化情報707へのポインタ704と次の処理群46
の最適化情報へのポインタ706より成る。各セグメント
の最適化情報707は、ポインタ720によってつながってお
り、708〜720のデータを保持する。

708は、情報707に対応するセグメントのセグメント管
理情報603へのポインタであり、710は、セグメント内の
最適化後中間コード30へのポインタである。712〜716は
セグメント間データフロー条件32へのポインタであり、
それぞれ、712はセグメント入口のデータフロー条件721
へのポインタ、714はセグメント出口のデータフロー条
件727へのポインタ、716は手続き呼び出しのデータフロ
ー条件733へのポインタである。718は、このセグメント
に対するプログラム変換情報20（第11B図）へのポイン
タである。720は、次のセグメントに対する最適化情報
へのポインタである。

以上が、最適情報18の大まかな構造であり、各処理群
46ごと、かつ、各セグメントごとに参照できるようにな
つている。

セグメント間データフロー条件32の内容を次に説明す
る。

セグメント入口に対するデータフロー条件721は、セ
グメント入口で定数値を持つと言う性質を最適化で用い
た変数の名前742とその値744を保持し、これを実現する
ために他の情報としてセグメント入口情報621へのポイ
ンタ722、変数名・定数値ペアを保持する情報741の先頭
のエントリへのポインタ724、次のセグメント入口のデ
ータフロー条件721へのポインタ726、変数名・定数値ペ
アを保持する情報741の次のエントリへのポインタ746を
含んでいる。

セグメント出口に対するデータフロー条件727は、セ
グメント出口でLiveでないと言う性質を最適化で用いた
変数を名前748を保持し、これを表現するための他の情
報として、セグメント出口情報627へのポインタ、Live
でない変数の変数名748を保持する情報747の先頭のエン
トリへのポインタ730、次のセグメント出口のデータフ
ロー条件727へのポインタ732、Liveでない変数名748を
保持する情報747の次のエントリへのポインタ750を含ん
でいる。

手続き呼び出しに対するデータフロー条件733は、あ
る手続き呼び出しで値が変更されないと言う性質を最適
化で用いた変数の名前752とある手続き呼び出しで値が
使用されることがないと言う性質を最適化で用いた変数
の名前755を保持し、これを表現するための他の情報と
して、手続き呼び出し情報633へのポインタ734、値が変
更されることがない変数の変数名752を保持する情報751
の先頭エントリへポインタ736、値が使用されることが
ない変数の変数名756を保持する情報755の先頭のエント
リへのポインタ738、次の手続き呼び出しのデータフロ
ー条件733へのポインタ740、値が変更されることがない
変数の変数名748を保持する情報751の次のエントリへの
ポインタ754、値が使用されることがない変数の変数名7
56を保持する情報755の次のエントリへのポインタ758を
含んでいる。

以上が、セグメント間データフロー条件32を表現した
ものであり、これがセグメント間データフロー情報16に
対して真になるかを判定するには、セグメント間データ
フロー条件32で表現されているデータフロー情報がセグ
メント間データフロー情報16から矛盾無く得られること
を判定すればよい。

次に、第11B図の説明をする。第11B図は、１つのプロ
グラム変換に対するプログラム変換情報20を表現してい
る。760はその様な１つのプログラム変換情報20のエン
トリである。このうち、762は最適化の種類、764は最適
化対象を表す情報781のリストへのポインタ、766は最適
化の適用方法を表す情報733のリストへのポインタ、768
はプログラム変換ドメインを表す情報787のリストへの
ポインタ、770はプログラム変換条件を表す情報777のリ
ストへのポインタ、772はプログラム変換情報20の次の
エントリへのポインタである。それぞれの情報がリスト
で表現されるのは、それぞれの情報が複数に分割される
ことを許すためである。

最適化対象を表す情報781は、最適化対象を含む行の
中間コードへのポインタ782,最適化対象の中間コードへ
のポインタ784,最適化対象を表す情報781の次のエント
リへのポインタ786より成る。

最適化の適用方法を表す情報733は、中間コードの変
換方法の一部を記述した情報774,最適化の適用方法を表
す情報733の次のエントリへのポインタ776より成る。

プログラム変換ドメインを表す情報787は、プログラ
ム変換ドメイン24の先頭の行の中間コードへのポインタ
778、最後の行の中間コードへのポインタ790、プログラ
ム変換ドメインを表す情報787の次のエントリへのポイ
ンタ792より成る。

プログラム変換条件を表す情報777は、データフロー
情報についての条件を記述した情報778と、プログラム
変換条件を表す情報777の次のエントリへのポインタ780
より成る。

以上で、最適化情報18の内容の説明を終える。

なお、最適化情報18は、実施されたプログラム変換に
ついての情報であるが、逆に、実施出来なかつたプログ
ラム変換についての情報を記録すると有用な場合もあ
る。例えば、ベクトル化処理では、解析中のループがベ
クトル化できるかを判定するのに多大な負荷を要し、あ
るループがベクトル化出来ないということが予め分かる
と、該ループに対するベクトル化解析が不要となり、最
適化処理を大巾の削減できる。前コンパイル時にベクト
ル化出来なかつたループは、該ループ内に修正がないな
ら再コンパイル時も同様にベクトル化出来ないので、ベ
クトル化解析が不要となり、最適化処理を大巾に削減で
きる。

また、実施出来なかつたプログラム変換についての情
報の記録に際して、最適化阻害要因も記録すると、プロ
グラム変換ドメイン内に修正があつた場合も最適化処理
を削減できる。この場合、修正後に該阻害要因が無くな
らないなら、より詳細な解析をしなくても、該プログラ
ム変換を抑止して良い。最適化阻害要因の他の利用方法
としては、該阻害要因をユーザに表示することにより、
プログラムのチユーニングに役立ててもよい。

以下では、第12A図のソースプログラム（サブルーチ
ンSUB1）を例として処理群46の動作状況や、最適化情報
18の内容を説明する。ただし、第12A図のプログラムに
対する処理のうち、処理群46の直前までの処理は、既に
説明した通りである。なお、前述のように、第12B図が
第12A図のプログラムに対する中間コードである。

まずは、初コンパイル時の処理であるが、初コンパイ
ル時には、各セグメントに対してセグメント内最適化50
を実行する。これに伴つて、最適化情報18が生成・記録
される。

最初の処理群では、第12B図の中間コード12のそれぞ
れのセグメントに対してセグメント内最適化50を実施す
る。その結果、最適化後の中間コード30は第16A図のよ
うになる。（ただし、セグメント１以外の最適化後中間
コード30は省略した） 次の処理群では、第16A図の最適化後中間コード30の
それぞれのセグメントに対してセグメント内最適化50を
実施する。その結果、最適化後の中間コード30は第16B
図のようになる。（ただし、セグメント１以外の最適化
後中間コード30は省略した。また、以下、他の処理群46
および他のセグメントで行う最適化の詳細は省略する） 実際にセグメント１に実施される最適化に対しては、
プログラム変換情報20の概要を第21A図（最初の処理
群）と第21B図（次の処理群）に示した。ただし、これ
らの図には再コンパイル時の再適用性についての情報80
2も含まれているが、これは後で説明する。最初の処理
群で実施する最適化としては、（１）行９内の式Ｋ＊Ｍ
＊４の１番目と２番目の両方をループ不変式としてルー
プDO20の外側（直前）へ移動する、（２）ループDO20の
ループ制御変数Ｊおよびこれを含む式に対するインダク
シヨン式リダクシヨン、このプログラム（サブルーチン
SUB1）の呼び出し時に必ず定数値100になる変数Ｍの参
照点への定数伝播、（４）このプログラム（サブルーチ
ンSUB1）の呼び出し時に必ず定数値３になる変数Ｌの参
照点への定数伝播が実施される。その結果として第12B
図のセグメント１の中間コード12は、第16A図のセグメ
ント１の最適化後中間コード30に変換される。第21A図
のプログラム変換情報20のうちプログラム変換履歴28
は、以上の処理をより詳しく記述したものである。プロ
グラム変換ドメイン24、すなわち、修正されたときにそ
れぞれのプログラム変換の再適用性に影響を与えるプロ
グラムの範囲は、ループDO20に対する最適化である
（１）と（２）ではループDO20全体（行８から行10）と
なり、（３）と（４）の定数伝播では直前のセグメント
入口から定数伝播先の行まで（それぞれ、行５から行８
まで、および、行４）となる。プログラム変換条件26、
すなわち、プログラム変換の適用に必要なデータフロー
条件は、（１）と（２）は無く、（３）では、セグメン
ト入口（行５）で変数Ｍの値が定数値100で、かつ、行
７の関数FNの呼び出しで変数Ｍの値が変更されないこと
であり、（４）では、セグメント入口（行４）で変数Ｌ
の値が定数値３であることである。また、これらのプロ
グラム変換条件26の中からセグメント間データフロー情
報16についての条件を抜き出した情報であるセグメント
間データフロー条件32は、セグメント入口（行４）で変
数Ｌの値が定数値３であり、かつ、セグメント入口（行
５）で変数Ｍの値が定数値100であり、かつ、行７の関
数FNの呼び出しで変数Ｍの値が変更されないことであ
る。第14図の721,721A,741,741A,733,747の情報は、こ
のセグメント間データフロー条件32を具体的に表現した
ものである。第14図は、本適用例における最適化情報18
の内容を示し、特に、セグメント１の最初の処理群での
最適化情報18（707とその右側の情報）と２番目の処理
群での最適化情報18（707Aとその右側の情報）を示して
ある。ただし、最適化後中間コード30とプログラム変換
情報20は、別の図に示してある。すなわち、最適化後中
間コード30は前述の通り第16A図および第16B図で示して
あり、プログラム変換情報20は処理群１についてのもの
のみを第15図に示してある。第15図では、特に、（３）
の定数伝播に対応するプログラム変換情報のみが明示さ
れている。第15図の内容は、第21A図のプログラム変換
情報20のうち、最初の定数伝播（３）についてのものを
第11B図の形式で表現しただけである。第15図におい
て、781,781A,781B,781Cはプログラム変換の適用対象を
表現し、773,773Aはプログラム変換の適用方法を表現
し、787はプログラム変換ドメイン24を表現し、777,777
Aはプログラム変換条件26を表現している。

次の処理群のセグメント内最適化50では、第21B図に
示されるように、共通式削除が４回と不要コード削除が
１回実施される。それぞれのプログラム変換ドメイン24
は、共通式削除では、共通式が最初に現れるところから
最後に現れるところまでであり、不要コート削除では、
削除される行からセグメント出口までである。また、プ
ログラム変換条件26は、この適用例の共通式削除では無
く、不要コード削除ではセグメント出口（行11）におい
て変数Ｊの値がLiveでないことである。セグメント間デ
ータフロー条件32は、セグメント出口（行11）において
変数Ｊの値がLiveでないことであり、第14図では、733
と751の情報で表現されている。

第17図に、全ての処理群46での全てのセグメントに対
するセグメント間データフロー条件32を要約した表を示
す。最初の処理群（処理群１）では、ループ不変式移
動，インダクシヨン式リダクシヨン，定数伝播などが実
施され、次の処理群（処理群２）では、共通式削除，コ
ピー伝播，不要コード削除などが実施され、最後の処理
群（処理群３）では、最適レジスタ割り当てが実施され
る。これらの最適化に伴い各処理群の各セグメントの最
適化語中間コード30の再利用に必要なセグメント間デー
タフロー条件32が、本図に示されている。セグメント１
の処理群１と処理群２でのセグメント間データフロー条
件32については既に説明したが、他のセグメント間デー
タフロー条件32は、その内容を示すためには実施された
最適化についても記述する必要があるので、詳細は省略
する。

以上で、適用例における処理群46の初コンパイル時の
処理と記録される最適化情報18の説明を終える。

次に、適用例における処理群46の再コンパイル時の処
理について説明する。再コンパイル時に与えられる修正
情報４は第18A図に示されたものが与えられるものとす
る。これに加えて、手続き間データフロー情報15は第18
B図のように変化したものとする。

この時、これに対する更新後の中間コード12とセグメ
ントの分割の仕方およびセグメントの最適化状態番号60
8は前述のように第19図に示されている通りになる。特
に、セグメント４は、最適化状態番号608が０であり、
初めから最適化し直す必要があることが示されている。

また、手続き間データフロー情報15の変化に対応し
て、セグメント間データフロー情報16も変化し、各セグ
メントの入口で変数Ｎは定数ではなくなる。これに伴つ
て、第17図に示されたセグメント間データフロー条件32
のうち、処理群１のセグメント３の条件が偽になる。す
なわち、処理群１において、セグメント３では、セグメ
ント入口（行17）で変数Ｎの値が定数値150で無くなる
ため、セグメント間データフロー条件32が偽になる。ま
た、行27と置換されて挿入された代入文「Ｂ［Ｋ＊４］
＝Ｇ」により、Ｇの値がセグメント２の出口以降で使用
されるようになるため、処理群３のセグメント２でのセ
グメント間データフロー条件32が偽になる。更に、他の
セグメント間データフロー条件32は全て真になる。すな
わち、変数Ｌまたは変数Ｍの値は再コンパイル時も変わ
らないし、残りのセグメント間データフロー条件32は変
数I,J,K,W1,W2のLive性に関する条件であり、再コンパ
イル時の中間コード12（第19図）を解析するとこれらの
条件も真になることが分かり、他のセグメント間データ
フロー条件32は全て真になる。

以上により、再コンパイル時の処理は第20図に示した
ようになる。

まず、処理群１での処理は、セグメント１では、セグ
メント内に修正マーク70付きの中間コードを含み、セグ
メントの修正有りフラグ610が立つているため、前プロ
グラム変換再適用60が実施され、セグメント２では最適
化後中間コード中間コード再利用58が実施され、セグメ
ント３では、修正が無いがセグメント間データフロー条
件32が偽になるため、前プログラム変換再適用60が実施
され、セグメント４では、最適化状態番号608が０であ
るため、初コンパイル時の処理が行われる。

次に、処理群２の処理は、セグメント１では、修正有
りフラグ610が立つているため、前プログラム変換再適
用60が実施され、更に、修正の影響が大きく前プログラ
ム変換再適用60で再適用されるプログラム変換の比率が
十分高くならないため、最適化状態番号608を−１にし
たのち初コンパイル時の処理が行われ、セグメント２で
は最適化後中間コード再利用58が実施され、セグメント
３では処理群１での処理によりセグメント内に修正マー
ク70付きの中間コードを含み、セグメントの修正有りフ
ラグ610が立つているため、前プログラム変換再適用60
が実施され、セグメント４では、最適化状態番号608が
０であるため、初コンパイル時の処理が行われる。

処理群３の処理では、セグメント１では、最適化状態
番号608が−１であるため、初コンパイル時の処理が行
われ、セグメント２では、修正は無いがセグメント間デ
ータフロー条件32が偽になるため、前プログラム変換再
適用60が実施され、セグメント３では修正有りフラグ61
0が立つているため、前プログラム変換再適用60が実施
され、セグメント４では、最適化状態番号608が０であ
るため、初コンパイル時の処理が行われる。

前コンパイル時の処理量を見積もるため、初コンパイ
ル時の処理の処理量を１、前プログラム変換再適用60の
処理量を0.5、最適化後中間コード再利用58の処理量を
０として計算すると、再コンパイル時の処理量は、処理
群１では、2.0（0.5＋０＋0.5＋１）、処理群２では、
3.0（0.5＋1.0）＋０＋0.5＋1.0）、処理群３では3.0
（1.0＋0.5＋0.5＋1.0）になり、全体で8.0（2.0＋3.0
＋3.0）になる。これに対して従来は、再コンパイル時
も初コンパイル時と同じ処理を行つていたので、処理量
は12.0（３＊4.0）になり、本発明の実施例では、従来
に比べて再コンパイル時の処理量が2/3（8.0/12.0）に
なつている。なお、本適用例は、再コンパイル時の処理
の説明をするため、処理の流れの組み合わせをなるべく
多くすることを目的とし、処理量は余り大きく削減され
ないが、一般には、処理量がもつと削減でき、1/2から1
/10にすることができる。

また、プログラム変換の再適用性の条件を表現するプ
ログラム変換ドメイン24とプログラム変換条件26の組み
合わせは、ある程度の任意性があり、例えば、プログラ
ム変換の再適用性の条件をプログラム変換条件26のみで
表現することもできる。そのようにすると、再適用性の
判定の処理量は多少大きくなるが、再適用性の判定の精
度は高くなるので、再適用できる場合が増える。例え
ば、第21A図に示されたプログラム変換のうち、変数Ｍ
の定数伝播では、５行目の次に修正マーク70が付いた中
間コードがあるために、再適用することができなかつた
が、実際には、５行目から８行目までの間では、変数Ｍ
の値は変更されないので、再適用性の判定を変えれば再
適用できる。第21A図と第21B図に示されたプログラム変
換のうち、再適用性可否802が不可（×）のものに対し
て、プログラム変換ドメイン24とプログラム変換条件26
の組み合わせを変えた場合の再適用性可否を第22図に示
す。第22図のプログラム変換情報20では、プログラム変
換ドメイン24をなしにして、プログラムの修正の有無を
利用するのは止め、変わりに、再適用性の条件を全てプ
ログラム変換条件26のみで表現してある。このようにす
ることにより、本当に再適用できなくなるものを省いて
は再適用正可否802が可（○）になる。このように、プ
ログラム変換ドメイン24とプログラム変換条件26の組み
合わせを変えることにより、再適用性判定の精度は変わ
る。修正の影響は最適化の種類によつてかなり異なるの
で、最適化の種別ごとにプログラム変換ドメイン24とプ
ログラム変換条件26の組み合わせを変えると、より効果
的である。

以上で、本発明の１実施例の説明を終える。

上記の実施例では、オブジエクトプログラム８はセグ
メントごとに再利用しなかつたが、コード生成47の処理
を第８図のように変えれば、オブジエクトプログラム８
もセグメントごとに再利用することができる。

第８図で、セグメント内生成コード501は各セグメン
トに対して生成されたオブジエクトプログラムである。
コード生成47では、セグメントごとにセグメント内生成
コード501を生成し、再利用するが、セグメント外のア
ドレスを参照する部分、例えば、セグメント外への分岐
などは、外部手続きのアドレスなどと同様に未解決にな
つており、セグメント間の外部シンボルとしてセグメン
ト間シンボル情報500に登録してある。オブジエクトプ
ログラム８としては、全セグメントのセグメント内生成
コード501に対して、セグメント間の外部シンボルのア
ドレス解決を行つたものを出力すればよい。このように
することにより、各セグメントごとに独立にコードを生
成する事ができ、セグメント内生成コード501をセグメ
ントごとに再利用することができる。

次に、コード生成47の処理の流れを説明する。

初コンパイルの処理では、502のセグメント内コード
生成を全セグメントに対して行つて、セグメント内生成
コード501を生成した後、504で、全てのセグメントのセ
グメント内生成コード501に対してセグメント間に跨っ
たアドレス解決を行い、オブジェクトプログラム48を生
成する。再コンパイル処理では、まず、506、507の処理
を全セグメントに対して実施する。ステツプ506では、
最後の処理群の対応するセグメントの処理で中間コード
再利用58が行われたかによつて、これが真の場合はステ
ツプ508へ進み、偽の場合は、初コンパイル時の処理502
を行う。ステツプ508では、処理中のセグメントのセグ
メント内生成コード501をそのまま再利用し、実際には
なにも処理しない。ステツプ510では、ステツプ504と同
じ処理をする。すなわち、全セグメントのセグメント内
生成コード501に対してセグメント間に跨ったアドレス
の解決を行いオブジエクトプログラム８を生成する。

以上のように、セグメントごとにセグメント内生成コ
ード501を記録・再利用することにより、コード生成処
理が削減されるので、コンパイル時間が短縮する。（た
だし、コード生成47の処理量は、最適化処理に比べれば
かなり小さく、1/10程度） 以上の実施例の構成では、中間コード12のセグメント
への分割、最適化処理の処理群46への分割、最適化後中
間コード再利用58,セグメント内最適化50でのセグメン
ト間データフロー情報16の利用など、全てのものを組み
合わせたが、これらのうち、一部のみを組み合わせて実
施しても最適化処理を削減することができる。また、条
件に応じて、その組み合わせを変えてもよい。すなわ
ち、最適化のレベル，各最適化の種類ごとの平均的な処
理量・効果・再適用性，ユーザの指定，対象プログラム
の平均的な修正量・修正の頻度・影響範囲の広さ，プロ
グラムの各部分の実行時間・実行比率などに従つて、一
番適切な方法で本発明を実施すると良い。

〔発明の効果〕

本発明によれば、再コンパイル時の最適化処理におい
て、最適化の途中の中間コードおよび最適化の処理内容
の記録を効率的に再利用でき、最適化処理の削減が図れ
るので、コンパイル時間を短縮する効果がある。

【図面の簡単な説明】

第１図は本発明の一実施例の構成図、第2A図再コンパイ
ル時の処理の説明図、第2B図は前プログラム変換再適用
の説明図、第３図は中間コード更新のフロー図、第4A図
はセグメント分割のフロー図、第4B図はセグメント更新
のフロー図、第５図はセグメント間データフロー解析の
フロー図、第６図は各処理群の詳細フロー図、第７図は
セグメント内最適化と前プログラム変換再適用の詳細フ
ロー図、第８図はコード生成結果の再利用を図るための
コード生成部の構成図、第９図はプログラム修正情報の
形式、第10図はセグメント管理情報およびセグメント間
データフロー情報、第11A図は最適化情報およびセグメ
ント間データフロー条件、第11B図はプログラム変換情
報、第12A図は本実施例の適用例における修正前のソー
スプログラム、第12B図は適用例における中間コードの
セグメント分割例、第13図は適用例におけるセグメント
管理情報およびセグメント間データフロー情報、第14図
は適用例におけるセグメント間データフロー条件、第15
図は適用例におけるプログラム変換情報、第16A図は適
用例における処理群１の処理の後の最適化後中間コー
ド、第16B図は適用例における処理群２の処理の後の最
適化後中間コード、第17図は適用例におけるセグメント
間データフロー条件の要約、第18A図は適用例における
再コンパイル時の修正情報の例、第18B図は適用例にお
ける再コンパイル時の手続き間データフロー情報の変化
の例、第19図は適用例における再コンパイル時の中間コ
ードのセグメント分割例、第20図は適用例における再セ
グメント時の各処理群の処理の要約、第21A図は適用例
におけるプログラム変換情報及びその再適用状況の要約
（セグメント１の処理群１での処理）、第21B図は適用
例におけるプログラム変換情報及びその再適用状況の要
約（セグメント１の処理群２での処理）、第22図は適用
例においてプログラム変換ドメインとプログラム変換条
件を変えたときのプログラム変換情報の再利用状況を示
す図である。 １…再コンパイルかを示すユーザ指示、２…ソースプロ
グラム、４…プログラム修正情報、６…コンパイラ、８
…オブジエクトプログラム、10…コンパイル情報、12…
中間コード、14…セグメント管理情報、15…手続き間デ
ータフロー情報、16…セグメント間データフロー情報、
17…セグメント内データフロー情報、18…最適化情報、
20…プログラム変換情報、24…プログラム変換ドメイ
ン、26…プログラム変換条件、28…プログラム変換履
歴、30…最適化後中間コード、32…セグメント間データ
フロー条件、40…構文解析、41…中間コード更新、42…
セグメント分割、43…セグメント更新、44…セグメント
間データフロー解析、45…セグメント内データフロー解
析、46…処理群、47…コード生成、50…セグメント内最
適化、51…条件判定、58…最適化後中間コード再利用、
60…前プログラム変換再適用、61…再適用率チエツク、
70…中間コードの修正マーク、99…行番号、501…セグ
メント内生成コード、608…最適化状態番号、610…セグ
メントに対する修正有りフラグ。

フロントページの続き (58)調査した分野(Int.Cl.⁶，ＤＢ名) G06F 9/44

Claims (17)

(57)【特許請求の範囲】
1. 【請求項１】最適化機能を有するコンパイラにおけるコ
   ンパイル方法であって、 プログラムのコンパイルの際に、コンパイラがプログラ
   ムのコンパイル単位であるサブルーチンや関数である手
   続きを更にいくつかの分割単位であるセグメントに分割
   し、 構文解析直後の中間コード、及びセグメントの切り方を
   示すセグメント管理情報を記憶し、 各セグメント毎にセグメント内のデータフロー情報を用
   いて最適化を行い、 各セグメント毎の最適化後中間コードを記憶し、 前記手続きの再コンパイル時に、ソースプログラムの修
   正に対応して中間コードとセグメント管理情報とを更新
   した後、修正を含むセグメント内で最適化を行い、修正
   を含まないセグメントでは、前コンパイル時の最適化後
   中間コードを利用することを特徴とするコンパイル方
   法。
2. 【請求項２】請求項第１項のコンパイル方法において、 最適化に先立って、複数のセグメント間に跨ったデータ
   フロー解析を行い、 各セグメント毎の最適化の際に、セグメント内のデータ
   フロー情報とセグメント間のデータフロー情報を用いて
   最適化を行い、 最適化後中間コードを記憶する際に、前記最適化が適用
   可能であるためのセグメント間データフロー情報につい
   ての条件であるセグメント間データフロー条件を記憶
   し、 再コンパイル時に、セグメント内に修正が無く、かつ、
   前記セグメントのセグメント間データフロー条件が真の
   場合に、前記セグメントの最適化後中間コードを再利用
   することを特徴とするコンパイル方法。
3. 【請求項３】請求項第１項のコンパイル方法において、 セグメントとして予め決められた大きさ以下のプログラ
   ム部分に含まれ、かつ、大きさが予め決められた大きさ
   以下の最内側ループ又は最内側多重ループは、前記分割
   を抑止することを特徴とするコンパイル方法。
4. 【請求項４】請求項第１項のコンパイル方法において、 ソースプログラムの修正によりあるセグメントが予め決
   められた大きさより小さくなった場合は、前記セグメン
   トを他のセグメントと連結し、逆に、予め決められた大
   きさより大きくなった場合は、前記セグメントを更に分
   割することにより、セグメントの大きさを適正に制御す
   ることを特徴とするコンパイル方法。
5. 【請求項５】最適化機能を有するコンパイラにおけるコ
   ンパイル方法であって、 コンパイル単位でプログラムを分割することにより、最
   適化処理全体の流れを時間的に分割し、 プログラムのコンパイル単位である手続きのコンパイル
   の際に、分割された処理のまとまりである処理群毎に最
   適化後中間コード、及び前記処理郡内で実施された全て
   の最適化が適用可能であるための手続き間データフロー
   情報についての条件である手続き間データフロー条件を
   記憶し、 既にコンパイルされた手続きの再コンパイルの際に、前
   記手続きが未修正であれば、処理群の処理順に最適化後
   中間コードの再利用性を判定し、 前記判定において、前記処理群が先頭の処理群であるか
   又は１つ前の処理群で最適化後中間コードが再利用され
   ていて、かつ、前記処理群に対する手続き間データフロ
   ー条件が真かを判定し、 前記再利用性の判定が真ならば、前記処理群の最適化後
   中間コードを再利用することを特徴とするコンパイル方
   法。
6. 【請求項６】請求項第５項のコンパイル方法において、 プログラムのコンパイルの際に、コンパイルの単位であ
   る手続きを更にセグメントに分割し、 構文解析直後の中間コード、及びセグメントの切り方を
   示すセグメント管理情報を記憶し、 最適化の際に、各処理群毎に、各セグメント内の最適化
   を行い、 各セグメントの最適化後中間コードとセグメント間デー
   タフロー条件を記憶し、 前記手続きの再コンパイル時に、ソースプログラムの修
   正に対応して中間コードとセグメント管理情報を更新し
   た後、処理群の処理順に、前記手続きの各セグメント毎
   に、最適化後中間コードの再利用性を判定し、 前記判定において、前記処理群が先頭の処理群であるか
   又は１つ前の処理群で最適化後中間コードが再利用され
   ていて、かつ、前記処理群に対する手続き間データフロ
   ー条件が真かを判定し、 前記再利用性の判定が真ならば、前記処理群の最適化後
   中間コードを再利用することを特徴とするコンパイル方
   法。
7. 【請求項７】最適化機能を有するコンパイラにおけるコ
   ンパイル方法であって、 コンパイル対象のプログラムに実施された各最適化の個
   々のプログラム変換の実施毎に、最適化の種類とプログ
   ラム変換の変換対象と変換方法からなるプログラム変換
   履歴を記憶し、 前記プログラムの再コンパイルの際に、前記プログラム
   の変換履歴に格納された各プログラム変換に対して、記
   憶された順番に、前記プログラム変換がプログラムの意
   味を変えずに前記プログラムの変換対象部分に再び適用
   可能かを判定し、前記判定が真ならば前記プログラム変
   換を前記プログラムに適用することを特徴とするコンパ
   イル方法。
8. 【請求項８】請求項第７項のコンパイル方法において、 前プログラム変換の再適用性判定は、 プログラムのコンパイルの際に、前記プログラムに実施
   されたプログラム変換のプログラム変換履歴、及び前記
   プログラム変換の適用を可能にするためのプログラム変
   換条件を記憶し、 前記プログラムの再コンパイルの際に、前記プログラム
   のプログラム変換履歴に記憶された各プログラム変換に
   対するプログラム変換条件が前記プログラムに対して真
   かを判定し、 前記判定の結果が真ならば、前記プログラム変換を前記
   プログラムに再適用できると判定することを特徴とする
   コンパイル方法。
9. 【請求項９】請求項第７項のコンパイル方法において、 前プログラム変換の再適用性判定は、 プログラムのコンパイルの際に、前記プログラムに実施
   されたプログラム変換のプログラム変換履歴、及びプロ
   グラムの修正の影響が前記プログラム変換の適用性に直
   接及ぶプログラム部分の範囲であるプログラム変換ドメ
   インを記憶し、 前記プログラムの再コンパイルの際に、前記プログラム
   のプログラム変換履歴に記憶された各プログラム変換に
   対するプログラム変換ドメインの無修正条件の真偽を判
   定し、 前記無修正条件は、プログラム変換ドメイン内に前コン
   パイル時以降の修正が無く、かつ、プログラム変換履歴
   に含まれたプログラム変換のうち実施対象がプログラム
   変換ドメインに含まれたプログラム変換よりも前に実施
   されたものは全て再適用性判定が真であるという条件で
   あり、前記無修正条件が真ならば、前記プログラム変換
   が再適用可能と判定することを特徴とするコンパイル方
   法。
10. 【請求項１０】請求項第７項のコンパイル方法におい
    て、 無修正条件の判定のために、プログラムの修正部分に対
    しては修正有りのマークを付け、更に、 無修正条件が偽となったプログラム変換においても前記
    プログラム変換の変換対象部分に修正有りのマークを付
    け、 無修正条件の判定においては、プログラム変換ドメイン
    内に修正有りマークが無い場合に前記無修正条件が真と
    判定することを特徴とするコンパイル方法。
11. 【請求項１１】請求項第８項のコンパイル方法におい
    て、 プログラムに実施された各プログラム変換のプログラム
    変換条件のうち、特定のプログラム部分の範囲内での修
    正の有無によって前記変換条件の真偽判定を代行できる
    ものに対して、前記変換条件を省略し、前記プログラム
    部分の範囲をプログラム変換ドメインに追加し、 前記プログラムの再コンパイルにおける前プログラム変
    換の再適用性判定の際に、前記プログラム変換ドメイン
    に対する無修正条件の真偽判定の結果を用いることを特
    徴とするコンパイル方法。
12. 【請求項１２】請求項第５項のコンパイル方法におい
    て、 プログラムのコンパイルの際に、処理群毎に、前記処理
    群で実施された全ての最適化のプログラム変換条件を要
    約した一括変換条件と、全てのプログラム変換ドメイン
    を合わせたプログラム範囲である一括変換ドメインと、
    全てのプログラムプログラム変換の対象を合わせたプロ
    グラム範囲である一括変換対象範囲、及び、前記処理群
    の終了時における一括変換対象範囲内の中間コードであ
    る最適化後中間コードを記憶し、 前記プログラムの再コンパイルの際に、処理群の処理順
    序に、前記処理群の最適化後中間コードの一括再利用性
    判定を行い、 前記一括再利用性判定では、前記一括変換ドメインに対
    する無修正条件が真で、かつ、前記一括変換条件が真な
    らば、真と判定し、 前記一括再利用性判定が真ならば、前記一括変換範囲に
    おいて、前記プログラムの中間コードを前記最適化後中
    間コードで置き換え、 前記一括再利用性判定が偽ならば、前記一括変換対象範
    囲において全ての中間コードに修正有りマークを付ける
    ことを特徴とするコンパイル方法。
13. 【請求項１３】請求項第６項のコンパイル方法におい
    て、 各処理群毎の各セグメント内最適化の際に、最適化後中
    間コードとセグメント間データフロー条件に加えて、プ
    ログラム変換履歴とプログラム変換条件とプログラム変
    換ドメインからなるプログラム変換情報を記憶し、 前記プログラムの再コンパイルにおける各処理群毎の各
    セグメント内最適化の際に、最適化後中間コードの再利
    用性判定が偽の場合には、前記プログラム変換情報のプ
    ログラム変換履歴に記憶された各プログラム変換のうち
    プログラム変換ドメイン内に修正が無く、プログラム変
    換条件が真となるものをプログラムに適用することを特
    徴とするコンパイル方法。
14. 【請求項１４】請求項第13項のコンパイル方法におい
    て、 各処理群毎に、全セグメントについてセグメント内最適
    化を行った後でセグメント間に跨った最適化を行うと伴
    に前記セグメント間最適化で実施されたプログラム変換
    のプログラム変換情報を記憶し、 再コンパイルの際に、全セグメントについてセグメント
    内最適化を行った後で、前記プログラム変換情報のプロ
    グラム変換履歴に記憶された各プログラム変換のうちプ
    ログラム変換ドメイン内に修正が無くプログラム変換条
    件が真となるものをプログラムに適用することを特徴と
    するコンパイル方法。
15. 【請求項１５】請求項第13項のコンパイル方法におい
    て、 ある処理群のセグメント内最適化で用いるセグメント間
    データフロー情報を、前記セグメントの入口における定
    数伝搬情報又は出口におけるライブ変数情報を含む、前
    記セグメントの入口・出口におけるセグメント間データ
    フロー情報とすることを特徴とするコンパイル方法。
16. 【請求項１６】請求項第13項のコンパイル方法におい
    て、 ある処理群のセグメント内最適化で用いるセグメント間
    データフロー情報を、前記セグメント内から呼び出され
    る呼び出し先手続きの手続き間情報とし、 前記セグメントのプログラム変換の際に、前記手続きの
    呼び出しに跨ったプログラム変換、及び呼び出し先手続
    きのインライン展開を含む、呼び出し先手続きの手続き
    間情報を用いた最適化を行うことを特徴とするコンパイ
    ル方法。
17. 【請求項１７】請求項第16項のコンパイル方法におい
    て、 手続き間情報として、手続き内の制御フローに依存せず
    に求められる手続き間情報を保持し、 前記手続き間情報の更新の際に、修正された部分を含む
    セグメント内の解析を行い、 前記解析の結果と未修正のセグメントの記録済み手続き
    間情報から前記手続きの新しい手続き間情報を求めるこ
    とを特徴とするコンパイル方法。