JP3337174B2

JP3337174B2 - コンパイル方法

Info

Publication number: JP3337174B2
Application number: JP18380294A
Authority: JP
Inventors: ディビッド・エム・ギレス
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1993-10-29
Filing date: 1994-08-04
Publication date: 2002-10-21
Anticipated expiration: 2017-10-21
Also published as: US5768595A; EP0651327A3; CA2102089A1; EP0651327A2; CA2102089C; JPH07129412A

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ターゲット・コンピュ
ータ上で実行するのに適したオブジェクト・コードを生
成するために、高水準言語で書かれたコンピュータ・プ
ログラムのソース・コードをコンパイルすることに係
り、更に詳細に説明すれば、プログラムの実行及びコン
パイル動作の両方において最大の効率を与えるために、
再コンパイル技術を用いて前述のコードを最適化するこ
とに係る。

【０００２】

【従来の技術】高水準言語のステートメントは、そのコ
ンパイル中に、当該ステートメントを実現することがで
きる手続きに変換される。しかし、これらの手続きは、
この言語ステートメントが生じうる任意の環境において
機能できるものでなければならないから、生成済みのコ
ードは、最適化を受けない限り、大きな冗長性と妥協と
を含むことになる。本明細書において用いられる「手続
き」という用語は、コンパイル時に、一の呼び出し位置
（サイト）からの一の手続き呼び出しに帰着するよう
な、ルーチン及び機能を含むものとして解されねばなら
ない。

【０００３】最適化とは、コンパイル・プロセスの効率
を改善するために、コンパイルを特徴付けるようなソー
ス・コード、オブジェクト・コード、又は任意の中間コ
ードに適用される修正のために使用される総括的な用語
である。本明細書において用いられる「効率」という用
語は、プログラムを開発する際に、繰り返し行われる再
コンパイルが次第に必要となることを念頭において、最
終的なオブジェクト・コードの実行速度を改善するこ
と、オブジェクト・コードのサイズを減少させること、
又はプログラム開発時の生産性の向上を目的としてコン
パイル速度を改善することを意味する。

【０００４】最適化は、コンパイル・プロセス中の種々
の段階で行われるが、最適化の技術は、冗長性及び不用
コードを除去するように、ソース・コード又は中間コー
ドを修正するフロント・エンド型と、実行速度を改善す
るように、生成済みのオブジェクト・コードを修正する
バック・エンド型の、２つのカテゴリに分類される。

【０００５】プログラム可能な汎用コンピュータ内で用
いられる中央処理装置は、プログラムの実行中に用いら
れるデータ項目を保持するためにハードウェア・レジス
タを広範に使用して、メモリの参照に関連するオーバヘ
ッドを回避するようにしている。このようなレジスタの
数、サイズ及び使用制限は、プロセッサごとに大きく変
化するけれども、かかるハードウェア・レジスタを効率
的に管理することが、コンパイラの最適化に係る主要な
側面を形成している。かかるハードウェア・レジスタの
管理に関係する一般的原理が、次の文献に開示されてい
る。K.M. Gilbert, "Effective Register Management D
uring Code Generation",IBM Technical Disclosure Bu
lletin, Jan. 1973, pp. 2640-2645（文献１）。また、
縮小命令セット・コンピュータ（ＲＩＳＣ）用のコンパ
イラにおける最適化技術が、次の文献に開示されてい
る。O'Brien et al., "Advanced Compiler Technology
for the RISC System/6000Architecture", IBM RISC sy
stem/6000 Technology, published 1990, IBM Corp., p
p. 154-161（文献２）。これらの文献では、ハードウェ
ア・レジスタの効率的な使用の重要性が強調されてい
る。

【０００６】通常のプロセッサでは、汎用レジスタの数
が制限されているから、コンパイラは、これらの汎用レ
ジスタがコンパイル中に参照される任意の手続きによっ
て修正される可能性について、通常、悲観的な仮定をし
なければならない。コンパイラ又はプロセッサの性質に
従って、幾つかのレジスタは、手続きによって修正可能
な「揮発性」レジスタとして識別することができる。Ｉ
ＢＭ社のＲＩＳＣシステム／６０００に相当するターゲ
ット・プロセッサでは、多くのレジスタが揮発性であ
る。例えば、条件レジスタ０〜７のうちのレジスタ２〜
４と、汎用レジスタ０〜３１のうちのレジスタ３〜１２
と、浮動小数点レジスタ０〜３１のうちのレジスタ０〜
１３が、それぞれ揮発性である。個々の手続きは、全て
のレジスタ又はこれより少数のレジスタが修正を受ける
ことにより特徴付けられるが、一の手続きが呼び出され
る環境において、修正を受けるレジスタの実際の数は、
一層少ない。かかる情報は、今日まで、複数の手続きを
含む一のループにおいて殆ど使用されていなかった。通
常、一の手続きに入る場合には、その手続き自体又はそ
の手続きによって呼び出される他の手続きによって修正
を受ける全てのレジスタの内容を保存することが必要と
なる。このことは、保存動作（及び後続する復元動作）
を実現するのに必要なマシン・サイクルの数と、スタッ
クの使用という両方の観点から、著しいオーバヘッドを
課すことになる。

【０００７】

【発明が解決しようとする課題】本発明の目的は、処理
すべきコードの量を減少させることによって、前述の望
ましくないオーバヘッドを減らすとともに、他の技術を
適用した場合のコンパイル時間の見地から効率を向上さ
せるための、前述のバック・エンド式の最適化技術を与
えることにある。

【０００８】

【課題を解決するための手段】本発明は、ターゲット・
コンピュータ上で実行可能なプログラムを与えるため
に、高水準言語又は中間言語で書かれた複数のソース・
コード・モジュールからコンピュータ・プログラムをコ
ンパイルする方法を与える。このコンパイル方法は、（イ）前記複数のソース・コード・モジュールの各々を
コンパイルするステップと、（ロ）少なくとも１つの前記ソース・コード・モジュー
ルのコンパイル中、並びにコンパイルされた前記ソース
・コード・モジュールを互いにリンクすることにより生
成された実行可能なプログラムの実行中の生成されたデ
ータを処理し、当該処理されたデータに基づいて、前記
コンピュータ・プログラム内で可能な複数の手続きから
成る一の呼び出しグラフを生成するとともに、前記コン
ピュータ・プログラムの通常の実行中に稀にしか呼び出
されないか若しくは全く呼び出されないターゲット手続
き、又は前記コンピュータ・プログラムの通常の実行中
の一の呼び出しから復帰しないターゲット手続きを識別
するステップと、（ハ）前記複数の手続きを前記呼び出しグラフにより示
されている呼び出し順序に関連する順序で再コンパイル
するステップであって、前記復帰しないターゲット手続
き以外の前記識別されたターゲット手続きの再コンパイ
ルを、当該ターゲット手続きにより修正可能な全てのハ
ードウェア・レジスタの内容を保存及び復元するための
コードを当該ターゲット手続きの入口及び出口にそれぞ
れ含ませた上で、遂行する再コンパイルのステップとか
ら構成されている。

【０００９】通常の手続き内（intraprocedural ）式の
最適化技術とは異なり、本発明の実現形態は、手続き間
（interprocedural ）関係に依存している。従って、稀
にしか使用されない手続き、又は殆ど使用されない手続
きは、より頻繁に使用され且つこの手続きを呼び出す他
の手続きの性能を改善するために、その性能を低下させ
るような態様で修正される。本発明を適用するために
は、これらの手続き間関係を分析せねばならない。よっ
て後述する本発明の実施例のように、そのような分析を
利用することができる他の最適化技術と関連させて本発
明を適用することが有利であり且つ便利であるし、そし
てこの分析の性質としてこのことを考慮することができ
る。しかし、かかる他の最適化技術は、本発明の一部を
形成するものではない。

【００１０】

【実施例】本発明を実現するために、一のプログラム
は、２度コンパイルされなければならない。第１のコン
パイルは、手続き間関係に関する情報を収集するための
ものであり、第２のコンパイルは、収集されたこれらの
情報を適用するためのものである。

【００１１】従って、図１のコンパイラ中に組み込まれ
ているシステムは、２パス・システムである。コンパイ
ル時間に遂行される第１のパスは、コンパイルされる各
手続き用のサマリ（要約）情報を収集する。リンク時間
に遂行される第２のパスは、かかる収集済みの情報を併
合し、この併合済みの情報を使用して、アプリケーショ
ン全体に対する一の手続き間解答（solution）を計算す
る。次に、最適化を増強するために、この手続き間解答
を用いて、アプリケーションが再構成される。図１に示
した実施例では、ソース・コード・モジュールをコンパ
イルするためにコンパイラ２が呼び出される際に、コン
パイラ２に一のコマンド・オプションが与えられると、
コンパイラ２は、コンパイルの対象であるそれぞれの手
続きに関する手続き間情報を収集する。また、コンパイ
ラ２によって生成されたオブジェクト・コードをリンク
するためにコンパイラのループ・モジュール４（リンカ
を用いることも可能）が呼び出される際に、ループ・モ
ジュール４に一のコマンド・オプションが与えられる
と、ループ・モジュール４は、前述の手続き間情報を用
いて前述のソース・コード・モジュールを再コンパイル
することにより最適化レベルを増強するとともに、この
ような手続き間アプローチで最適化されたオブジェクト
・コードのバージョンをリンクさせて高度に最適化され
た（golden）出力ファイル１０を形成する。

【００１２】コンパイル中の情報の収集は、指定された
コマンド・オプションを使用することによって開始され
る。ファイル及び各手続きのサマリ情報は、コンパイル
中に収集され、リンクにおいて使用するために、生成さ
れたオブジェクト・ファイル６に書き込まれる。各オブ
ジェクト・ファイル６は、追加の情報を保持する処の、
適当に識別される一のセクションに関連付けられる。こ
の情報は、必要に応じて、別個のファイル内に収集する
ことができる。

【００１３】このサマリ情報は、次の情報を含んでい
る。・完全に修飾されたソース・ファイルの名称。・含まれている各手続きの名称（曖昧さを避けるため十
分な情報を持つ）。・呼び出されるコンパイラ・オプション。・各手続き内の全ての呼び出し位置のリスト（識別の際
の曖昧さを避けるため十分な情報を持つ）。・各呼び出し位置における諸パラメータの一定の伝播情
報。・各手続きの別名情報。・他の最適化技術（例えば、インライン化及びクローン
化）の適切さに関する情報。即ち、各手続きの中間言語
のサイズ、自動的なストレージの使用及び一定のパラメ
ータ等。

【００１４】・呼び出し位置のポスト優性（post-dominance）の情
報。・モレル−レインベスト（Morel-Reinvest）アルゴリズ
ム及び共通部分式アルゴリズムにより計算されるよう
な、諸ループからのコード移動の大きさ。・レジスタ・プレッシャ／カラーリング（使用）の情
報。

【００１５】アプリケーション内の全てのファイルがコ
ンパイルされた場合、ユーザは、前述のコマンド・オプ
ションによって、コンパイラ２を通してそのループ・モ
ジュール４を再び呼び出す。リンク時間ドライバ８は、
オブジェクト・ファイル６からサマリ情報を読み取り、
オプションとして、オブジェクト・ファイル６の以前の
リンク動作によって生成された一の出力ファイル上で一
のプロファイラ（profiler）を実行することにより生成
されるプロファイル・サンプル１２からサマリ情報を読
み取るとともに、公知の呼び出しグラフ技術を用いてア
プリケーションの呼び出しグラフを計算する。

【００１６】例えば、次のアプリケーションを検討す
る。

【表１】

【００１７】図２は、前述の例の呼び出しグラフを示し
ている。リンク時間ドライバ８によってアプリケーショ
ンの呼び出しグラフを作成することを可能にする情報
は、３つのオブジェクト・ファイルの各々に保持されて
いる。本発明によって最適化レベルを増強するために、
リンク時間ドライバ８は、アプリケーションのボトム・
アップ型（図１に示すトポロジの順序の逆）の再コンパ
イル１４を行わせる。図示の例における順序は、 a.c
（foo）、ａ.c（foobar）、b.c（bar）及び a.c（mai
n）である。最適化機構は、アプリケーション全体に対
する手続き間解答が計算された後に、リンク時間ドライ
バ８により、この順序で反復的に呼び出される。

【００１８】手続き間解答は、次の幾つかのステップで
計算される。・各手続き用の別名情報は、呼び出しグラフ内でルート
（根）に向かって上方に伝播される。・一定のパラメータ情報は、呼び出しグラフ内でリーフ
（葉）に向かって下方に伝播される。・もし、プロファイル情報が使用可能であれば、このプ
ロファイル情報が読み取られ、そして呼び出しグラフの
エッジがトラバース・カウントによりマークされる（図
３参照）。・本発明の最適化技術を含む種々の最適化技術の候補を
識別するためのヒューリスティック・アルゴリズムが実
行される。

【００１９】アプリケーション中の各手続きが再コンパ
イルされる場合、レジスタ使用情報２６が保存され、そ
して後続する再コンパイル中にフィードバックされる。
特定のハードウェア・プラットフォーム用に設計された
コンパイラについては、使用可能なハードウェア・レジ
スタのうちどのレジスタが、コンパイルされた手続きに
よって修正され得るか、という点に関する規則を考慮す
ることが有用である。例えば、ＲＩＳＣシステム／６０
００に相当するターゲット・プロセッサでは、リンケー
ジ規則は、汎用レジスタ３〜１２と、浮動小数点レジス
タ０〜１３と、条件レジスタ９、１、５、６及び７と、
カウント・レジスタとが、それぞれ揮発性であることを
指示する。他方、このような情報が存在しない場合、呼
び出し側（発呼側）は、揮発性レジスタ内に保持されて
いる値が、呼び出される側（被呼側）によって消去され
ていることを仮定しなければならない。

【００２０】コンパイラ２は、リンク時間に、呼び出し
グラフのトポロジの順序とは逆の順序で、アプリケーシ
ョンを再コンパイルする。従って、被呼側の手続きは、
それらの発呼側の手続きよりも前に再コンパイルされ
る。被呼側における実際のレジスタの使用情報２６を共
有メモリ２８内に格納することによって、無変更の揮発
性レジスタは、依然として発呼側によって使用すること
ができる。このプロセスは、レジスタ・リサレクション
（register resurrection −レジスタ復活）と呼ばれ
る。レジスタ・リサレクションは、一のアプリケーショ
ンが、使用可能なハードウェア・レジスタのファイル
を、一層良好に使用することを可能にする。このアプリ
ケーションが遭遇するストレージ・トラフィックは、一
層少なくなるはずである。なぜなら、一の手続きにサー
ビスするために使用可能なハードウェア・レジスタが不
十分であることに起因するデータ・スタックとのトラフ
ィックを表す、レジスタ保存／復元コード及びレジスタ
・スピル（spill ）コードが何れも縮小されているから
である。

【００２１】分析の結果、一の手続きに対する一の参照
がレジスタの内容を無効化することが決定されたとして
も、呼び出し（発呼側）手続きにおいて何れにせよ必要
とされるレジスタの保存及び復元コードを移動すること
には利益がある。この技術が利益をもたらすのは、デバ
ッグ及びエラー処理手続きのように、この手続きが極め
て稀にしか参照されないことが分かっている場合であ
る。

【００２２】１例を挙げる。

【表２】 Preserve.f Do I=1,00000 C ... （多くのスカラ又はアレイを操作するコード） IF (X1(I).GT.1.OE32) CALL ERROR1(X1(I)) IF (x1(I).LT.0.1E-32) CALL ERROR2(X1(I)) C ... （これらのスカラ又はアレイでさらに処理を行うコード） ENDDO

【００２３】呼び出された（被呼側）手続きの修正がな
いと、コンパイラ２は、リンケージ規則の揮発性レジス
タが ERROR1 及び ERROR2 への参照によって無効化され
ること、従ってこれらの参照前にレジスタ内にあり且つ
これらの参照後に必要とされるような任意の値を復元す
るために追加的なコードが生成され得ることを仮定す
る。この追加的なコードは、性能を劣下させ、当該ルー
プのコード・サイズを増加させるだけでなく、命令キャ
ッシュ・ミスに起因する遅延を増加させる。しかし、も
し、 ERROR1 及び ERROR2 が殆ど呼び出されないような
ものであれば、無効化されたレジスタを保存及び復元す
るためのコードは、それぞれの手続き中に移動すること
ができるので、これらの値を参照中の手続き内に再ロー
ドする必要はないのである。こうするため、レジスタの
保存コードが各手続きの開始点に置かれ、レジスタの復
元コードが各手続きの終了点に置かれる。

【００２４】このようにすると、一層大きなオブジェク
ト・ファイルを生じるけれども、レジスタ保存コードが
命令キャッシュ内に殆どロードされず、しかも殆ど実行
されないという理由で、命令キャッシュ及びプロセッサ
の使用率が改善されることになる。

【００２５】レジスタの保存及び復元コードを移動する
ことは、エラー処理又は範囲検査用の手続きについても
有用である。但し、エラー又は範囲外の値が殆ど見出さ
れないことを条件とする。

【００２６】もし、参照された一の手続きが一のプログ
ラムを常に終了させるのであれば、この手続きが参照さ
れる時に諸レジスタを無効化する理由はない。次のＣの
例では、標準的な機能 exit() が一の条件ブロック内で
呼び出される。通常、コンパイラ２は、 exit() に対す
る呼び出しにより無効化されるであろう任意の要求され
たレジスタを保存し且つ復元するために、この呼び出し
の前後にコードを挿入する。

【００２７】

【表３】

【００２８】コンパイラ２は、 exit() が決して復帰し
ないような機能であること、従ってbailout() への参照
において諸レジスタを保存することが重要でないことと
を知らない。このことは、ＲＩＳＣシステム／６０００
のターゲット環境におけるＣ機能の abort()（放棄）及
び terminate()（終了）（又は assert()（表明））、F
ORTRAN の STOP（停止）ステートメント及び他の終了手
続きにおいても、同様にあてはまる。リンカに対して
は、一の exit サブ・オプションを指定することによっ
て、ある種の標準的な手続きを終了手続きとして取り扱
うように命令することができる。このサブ・オプション
は、手続きを終了させることはできない。しかし、呼び
出しグラフは、一の手続きが常に一の終了手続きを呼び
出すことを設定することができ、そして、この情報を呼
び出しチェーン内の上方へ伝播させることができる。こ
のようにすると、終了手続きに対する参照に関連してレ
ジスタが保存されないので、この終了手続きが呼び出さ
れる際にレジスタを保存することが重要でなくなる。

【００２９】しかし、本発明の最も利点のある適用例
は、プロファイル・データのフィードバックと関連して
いる。プロファイル・サンプル１２において決して呼び
出されることのない諸機能は、予定の頻度よりも少ない
頻度で呼び出される他の機能のように、前述のように修
正される。プロファイル情報は、単一のラン（実行）か
ら収集してもよいし、幾つかの代表的なランからユーザ
が収集してもよい。何れの場合でも、得られたサンプル
は、実行中のアプリケーションを表すものと見なされ、
これに従って修正用の手続きが選択される。図３から理
解できるように、呼び出しグラフ中にプロファイル情報
を含ませると、頻繁に呼び出される手続き１６と、稀に
しか呼び出されないか又は決して呼び出されない手続き
１８、２０、２２との間の境界にある手続きを、前述の
ように修正することができる。ここで留意すべきは、頻
繁に実行される一の手続きが呼び出し頻度の低い一の手
続きを呼び出す点においてのみ、本発明を適用すること
が必要とされるに過ぎない、ということである。なぜな
ら、呼び出し頻度の低い手続きは、本質的にそれ自体で
頻度の低い呼び出しを行うに過ぎないからである。

【００３０】インライン化やクローン化のような他の最
適化技術は、前述のプロファイル情報の使用から利益を
受ける。呼び出されることのない手続き、又は稀にしか
呼び出されないような手続きのインライン化又はクロー
ン化は利益がない。この結果、過剰なインライン化によ
って生ぜられるようなコード・サイズの爆発的増大につ
いての懸念が直ちには表面化しないという理由で、使用
頻度の高い手続きのインライン化又はクローン化を積極
的に進めることができる。図３に示されている一般的な
呼び出しグラフの各エッジには、プロファイルのフィー
ドバックを介して、ドラバース頻度のラベルが表記され
ている。この情報を利用して手続き１８及び２０を修正
すると、かかる修正によって構築された「ファイアウォ
ール」２４より下のサブ・トリー全体を隔離することに
より、手続き１８、２０及び２２によるレジスタの使用
が手続き１６に対して不可視となることを保証する。ま
た、この情報は、ファイアウォール２４より上の呼び出
しに対し、インライン化又はクローン化を適用しても、
利益がないことを表す。

【００３１】一旦、一のコード・モジュール中に一の
「ファイアウォール」を構築することが必要であると決
定された場合は、図４の流れ図に示されている生成ステ
ップが続けられる。

【００３２】レジスタ割り当て処理４０は、ターゲット
・コンピュータ上にあるレジスタの各非結合（disjoin
t）クラスごとの解答を計算するために、プログラム・
コードを一のレジスタ割り当てアルゴリズムを通すこと
によって達成される。適切なレジスタ割り当てアルゴリ
ズムは、例えば、次の文献に開示されている。Chaitin
et al.,"Register Allocation and Spilling Via Graph
Coloring",Computer Language, 6：47−57, 1981（文
献３）。

【００３３】レジスタ割り当て処理４０は、各レジスタ
・クラスごとに、レジスタ割り当て出力４２を発生す
る。

【００３４】レジスタ割り当てループ４０、４２の複数
のパスは、ターゲット・コンピュータ用の全てのレジス
タ・クラスに対する解答を計算し且つこの解答を割り当
てるのに必要となることがある。例えば、ＲＩＳＣシス
テム／６０００に相当するターゲット環境では、３つの
レジスタ・クラスが存在するから、レジスタ割り当てア
ルゴリズムの３回のパスが必要である。

【００３５】全てのレジスタ・クラスについてレジスタ
の割り当てを行った後、修正済みの全ての揮発性レジス
タを保持すべき自動スタックのストレージ部分を予約す
るために、プログラム４４のプロローグ内にコードが生
成される。勿論、このスタック・ストレージは、実行時
に割り当てられる。

【００３６】次に、修正済みの各レジスタごとに、各モ
ジュール４６内でコードが生成される。即ち、予約済み
のストレージ内にある次に使用可能なスロット中に適当
な幅の格納を実行するためのコードが各モジュール４６
のプロローグ内に生成され、そしてこの予約済みのスト
レージ内にある同じスロットから同じ揮発性レジスタへ
適当な幅のロードを実行するためのコードが各モジュー
ル４６のエピローグ内に生成される。

【００３７】コンピュータ・プログラムにおける生成済
みの各モジュールは、プロローグ・コードと、当該モジ
ュール用のメイン・コードと、エピローグ・コードとを
含んでいる。

【００３８】図５を参照するに、本発明のコンパイル方
法を実現することができる汎用コンピュータ３０は、通
常のコンパイラ又はクロス・コンパイラの何れが実現さ
れるのかに依存して、コンパイルのターゲット・コンピ
ュータと同じか又は異なることがある。汎用コンピュー
タ３０は、一のユーザ・インタフェースを与える通常の
コンソール３２と、データ・ストレージ３４及びプログ
ラム・ストレージ３６を持っている。適当な媒体に格納
されているコンピュータ・プログラム３８は、汎用コン
ピュータ３０をコンパイル装置として構成するために、
汎用コンピュータ３０のプログラム・ストレージ３６内
にロードされる。データ・ストレージ３４は、汎用コン
ピュータ３０又は別個のコンピュータを使用して実現さ
れる処の、プロファイラ４０からの入力データを受け取
ることができる。

【００３９】ここで留意すべきは、このコンパイラは、
その入力として、通常の高水準言語、又は高水準言語が
既に変換されている中間言語（ＩＬ）の何れかを受け取
ることができる、ということである。後者の中間言語が
有利となるのは、一のコンパイラを構成する多くのプロ
グラムを幾つかの異なった言語に対して共通にすること
により、これらの言語を適当なフロント・エンド・モジ
ュールによって共通の中間言語に変換することができる
ような場合である。

【００４０】

【発明の効果】以上のように、本発明によれば、高水準
言語で書かれたコンピュータ・プログラムをターゲット
・コンピュータ上で実行可能なオブジェクト・プログラ
ムのソース・コードにコンパイルする場合に、他のコン
パイル技術で処理されるコードの量を減少させて、プロ
グラムの実行動作及びコンパイルの動作の両方に最大の
効率を与えることができる。

【図面の簡単な説明】

【図１】本発明を実現するコンパイラの関連部分の構成
を示すブロック図である。

【図２】簡単なプログラムの呼び出しグラフを示す図で
ある。

【図３】本発明の情報が呼び出しグラフに適用される場
合の動作を示す図である。

【図４】本発明の方法を実施するためのステップを示す
流れ図である。

【図５】本発明を実現するために使用される装置のブロ
ック図である。

【符号の説明】

２コンパイラ４ループ・モジュール６、１０オブジェクト・ファイル８リンク時間ドライバ１２プロファイル・サンプル１４再コンパイル２４ファイアウォール２６レジスタ使用情報２８共有メモリ３０コンピュータ３２コンソール３４データ・ストレージ３６プログラム・ストレージ３８コンピュータ・プログラム４０プロファイラ

───────────────────────────────────────────────────── フロントページの続き (72)発明者ディビッド・エム・ギレスカナダ国オンタリオ州、ニューマーケット、フィフス・コート 838 (56)参考文献特開平３−172936（ＪＰ，Ａ) 特開平１−121938（ＪＰ，Ａ) 特開平３−91038（ＪＰ，Ａ) 特開平３−67336（ＪＰ，Ａ) 特開平４−215144（ＪＰ，Ａ) ＳＯＦＴＷＡＲＥ−ＰＲＡＣＴＩＣＥＡＮＤＥＸＰＥＲＩＥＮＣＥ，Ｖｏｌ．21，Ｎｏ．12（1991−12）Ｐ．1301 −1321 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/44

Claims

(57)【特許請求の範囲】

【請求項１】コンピュータ・プログラムの実行中に使用
されるデータを格納するために使用可能な複数のハード
ウェア・レジスタを有するターゲット・コンピュータ上
で実行可能なオブジェクト・コードを与えるために、高
水準言語又は中間言語で書かれた複数のソース・コード
・モジュールから前記コンピュータ・プログラムをコン
パイルする方法において、前記複数のソース・コード・モジュールの各々をコンパ
イルするステップと、少なくとも１つの前記ソース・コード・モジュールのコ
ンパイル中、並びにコンパイルされた前記ソース・コー
ド・モジュールを互いにリンクすることにより生成され
た実行可能なプログラムの実行中の生成されたデータを
処理し、当該処理されたデータに基づいて、前記コンピ
ュータ・プログラム内で可能な複数の手続きから成る一
の呼び出しグラフを生成するとともに、前記コンピュー
タ・プログラムの通常の実行中に稀にしか呼び出されな
いか若しくは全く呼び出されないターゲット手続き、又
は前記コンピュータ・プログラムの通常の実行中の一の
呼び出しから復帰しないターゲット手続きを識別するス
テップと、前記複数の手続きを前記呼び出しグラフにより示されて
いる呼び出し順序に関連する順序で再コンパイルするス
テップであって、前記復帰しないターゲット手続き以外
の前記識別されたターゲット手続きの再コンパイルを、
当該ターゲット手続きにより修正可能な全てのハードウ
ェア・レジスタの内容を保存及び復元するためのコード
を当該ターゲット手続きの入口及び出口にそれぞれ含ま
せた上で、遂行する再コンパイルのステップとから成
る、コンパイル方法。
【請求項２】前記識別されたターゲット手続きが、その
呼び出しによって前記コンピュータ・プログラムから出
て行く手続きを含んでいる、請求項１に記載のコンパイ
ル方法。
【請求項３】前記処理されたデータが、コンパイルされ
た前記ソース・コード・モジュールを互いにリンクする
ことによって生成される前記実行可能なプログラム上で
一のプロファイラを走行させることにより生成されるデ
ータを含み、前記ターゲット手続きが、稀にしか呼び出
されないものとして前記プロファイラによって識別され
る手続きを含んでいる、請求項１に記載のコンパイル方
法。
【請求項４】ハードウェア・レジスタの内容を保存及び
復元するための前記コードの前記識別されたターゲット
手続きへの導入が、当該コードを含む元の手続きのコー
ドに、プロローグ・コード及びエピローグ・コードを追
加することによって行われる、請求項１に記載のコンパ
イル方法。
【請求項５】前記手続きが、前記呼び出しグラフによっ
て示されている呼び出し順序とは逆の順序で再コンパイ
ルされ、前記ターゲット手続きの再コンパイルが、前記
ターゲット手続きのための呼び出し位置を含む手続きの
再コンパイルよりも先行する、請求項１に記載のコンパ
イル方法。