JPH09106351A - 変数リネーム方法 - Google Patents

Abstract

(57)【要約】 【課題】 命令スケジュールに有効な変数のみをリネー
ムし、かつ到達する定義が複数存在する場合も、効率良
く変数をリネームする。 【解決手段】 プログラムに対して、スーパーブロック
を生成し、実行頻度の高いスーパーブロックから順に、
依存グラフを作り、不要依存エッジを消去し、命令スケ
ジュールを行ない、順序が逆転した命令に対してのみ、
変数のリネームを行なう。さらに、到達する定義点が複
数ある場合に生じるコピー命令は、現在処理しているス
ーパーブロックよりも実行頻度の低いスーパーブロック
に出す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は最適化コンパイラに
おける変数のリネーム方法に関し、特に並列／パイプラ
イン式のコンピュータと共に使用する場合に適した方法
で、命令スケジュール後に必要な場合に限り、変数をリ
ネームすることで、不要な変数のリネームによる、コン
パイル時の無駄なメモリ使用を削減ことを可能にし、か
つ定義点が複数存在する場合も、コピー命令を実行頻度
の低い実行パス上に出すことにより、効率の良い変数の
リネームを可能にする、変数のリネーム方法に関するも
のである。

【０００２】

【従来の技術】近年、複数の命令を同時実行可能なスー
パースカラ方式のプロセッサが主流になり、このような
計算機上で、高速にプログラムを実行するために、プロ
グラム中から、より多くの並列実行可能な命令を抽出す
ることが、最適化コンパイラに対して求められている。

【０００３】最適化コンパイラにおける命令スケジュー
ラは、プログラム中からできるだけ多くの並列実行可能
な命令を抽出することを試みる。しかし並列実行可能な
命令の数は、プログラマによる変数の再定義や、コンパ
イラが、コンパイル中に生成する一時変数や、レジスタ
を再利用することにより生じる、人工的な逆依存や出力
依存によって制限される。

【０００４】この人工的な依存による並列性減少の問題
を解決するために、従来から変数のリネーム処理が行な
われている。変数のリネーム後、リネームによって不要
な依存を削除したプログラムに対して、命令スケジュー
ラが命令の再配置を行ない、プロセッサの並列度にみあ
ったオブジェクトコードを生成する。

【０００５】変数のリネームは、例えば次に示す処理で
ある。例として次の命令列を考える。命令S1で、変数X
を定義し、S1の後続命令S2において、S1で定義した変数
Xを使用している。またS2の後続命令S3で、再び変数Xを
定義している。この場合、S2はS1にフロー依存、S3はS2
に逆依存、S3はS1に出力依存している。

【０００６】S1からS2へのフロー依存は真の依存とも呼
ばれ、プログラム実行上必ず守られなければならない命
令間の順序関係を表している。一方S1、S3間の出力依
存、及びS1、S2間の逆依存は、人工的な依存であり、変
数のリネームにより削除できる依存である。

【０００７】リネーム処理ではまず、逆依存および出力
依存している、S3で定義される変数Xの名前を新たな名
前Yに変更する。次にS3の後続命令のうち、S3で定義さ
れるXの値を使用する命令S4があれば、S4内の変数XをY
に変更する。上記リネームにより、文S1、S2、S3の間
で、守らなければならない順序関係はS1、S2だけとな
り、S1、S3間、及びS2、S3間の順序はスケジューラが任
意に決定することが可能となる。

【０００８】リネーム後に行なうスケジュール処理は、
従来から基本ブロックを単位として行なわれている。し
かし基本ブロックを単位としたスケジューリングでは、
抽出できる並列性に限界がある。そのためより多くの並
列性を抽出するために、近年、スーパーブロックスケジ
ューリングと呼ばれる、基本ブロックを越えた命令スケ
ジューリング方式が開発されている。スーパーブロック
スケジューリングについては「Wen-mei W.Hwu, Scott
A.Mahlke, William T.Chen, Pohua P.Chang, Nancy J.W
arter, Roger A.Bringmann, Roland G.Ouellette,Richa
rd E.Hank, Tokuzo Kiyohara, Grant E.Haab, John G.H
olm, Daniel,M.Lavery. The Superblock:An Effective
Technique for VLIW and Superscalar Compilation. Jo
urnal ofSupercomputing 1993」において詳しく論じら
れている。

【０００９】これによると、スーパーブロックとは、''
制御の出口は複数あるが、制御の入口は一箇所である''
という性質を持つ基本ブロックの列である。スーパーブ
ロックは、分岐確率に基づいて行なわれる。図４は、ス
ーパーブロックの例である。図４におけるスーパーブロ
ック４０８は、基本ブロック４０１と４０２から構成さ
れる。スーパーブロック４０８への制御の入口は、先頭
の基本ブロック４０１の一箇所のみであり、出口は、基
本ブロック４０１と４０２の２箇所ある。

【００１０】スーパーブロックスケジューリングとは、
従来から行なわれている基本ブロック内のスケジューリ
ングを、複数の基本ブロックから構成される、スーパー
ブロックに対して行なうスケジュール方法である。

【００１１】

【発明が解決しようとする課題】従来のリネームには2
つの問題点がある。第1に、スケジュールに有効でない
変数のリネームも行なうという点が挙げられる。ここで
スケジュールに有効であるとは、変数のリネームによっ
て順序制約が解消された命令が、実際にスケジューラに
よって、並列実行されるように再配置される場合をい
う。従来のリネーム処理は、スケジュール処理の前に行
われており、リネーム処理の時点では、どの変数のリネ
ームが実際のスケジュールに有効かが分からない。この
ため従来のリネーム処理では、リネーム可能な全ての変
数のネームを行なう。これはコンパイル時に不要なメモ
リを使用することにつながる。

【００１２】従来のリネームの第２の問題点として、到
達する定義が複数ある場合、変数のリネームを行なわな
いという点が挙げられる。例えば、従来の技術での例を
用いると、S4でのXの使用に到達する定義が、S3におけ
るXの定義だけならば、S3及びS4の変数Xを新たな変数Y
に変更することで、リネーム処理は終了する。

【００１３】しかし、命令S5におけるXの定義もS4に到
達する場合、S3、S4におけるXのリネームに加え、S5か
らS4への実行パス上にS5で定義されるXの値を、リネー
ムによって新たに生成した変数Yにコピーする、コピー
命令を挿入する必要がある。このように使用に到達する
定義が複数ある場合もリネームを行なおうとすると、そ
のリネームがスケジュールに有効であるかどうかに関わ
らず、元のプログラムにないコピー命令を追加しなけれ
ばならない。したがって、実行命令数の増加という点か
ら、従来の変数のリネーム処理では、使用に到達する定
義が複数ある場合のリネームは行なわれていない。

【００１４】本発明の目的は、これらの課題を解決し、
(1)スケジュールに必要な場合だけ、変数のリネームを
行ない、かつ(2)変数の使用点に到達する定義点が複数
ある場合も、効率良く変数のリネームを行なう、ことを
可能にする変数リネーム方法を提供することである。

【００１５】

【課題を解決するための手段】上記の目的は、従来、命
令スケジュール処理の前で行なわれていたリネーム処理
を、スーパーブロックの実行頻度を考慮して、スケジュ
ール処理の後で行なうこと、具体的にはプログラム中か
らスケジュール単位としてスーパーブロックを生成し、
実行頻度の高いスーパーブロックから順に、以下の処理
を施すことで達成される。

【００１６】(1)現在のスーパーブロックに対する依存
グラフを生成する。依存グラフのノードは、スーパーブ
ロックを構成する命令であり、ノード間のエッジは命令
間の依存を表す。

【００１７】(2)生成された依存グラフから、逆依存、
出力依存エッジの消去可能性を検査し、消去可能なエッ
ジを消去する。また消去されたエッジが張られていた命
令対を、スケジュール後に順序が逆転可能な命令対とし
て登録する。ここで、依存エッジの消去条件としては、 a)リネーム対象の変数の使用点に到達する定義がただ一
つである、または b)リネーム対象の変数の使用点に到達する定義が複数あ
り、かつ、本使用点に到達する全て定義が現在処理して
いるスーパーブロック内にあるか、または、現在処理し
ているスーパーブロックより実行頻度の低いスーパーブ
ロック内にある、の２つを考慮する。

【００１８】(3)不要な依存エッジが切られた依存グラ
フに対して、命令のスケジュールを行なう。

【００１９】(4)スケジュール済み命令列内で、(2)で登
録した命令対の順序が、スケジュール前の順序と逆転し
ていれば、逆転した命令に対して、変数のリネーム処理
を行なう。この時、リネーム対象の変数の使用点に到達
する定義点が複数あるならば、コピー命令を生成し、現
在スケジュール中のスーパーブロック外、すなわち現在
スケジュールしているスーパーブロックよりも実行頻度
の低いスーパーブロックに、このコピー命令を挿入す
る。

【００２０】新たに生成されたコピー命令は、後に実施
される、より実行頻度の低いスーパーブロックのスケジ
ュールにおいて、スーパーブロック内の他の命令と共に
スケジュールされる。

【００２１】実行頻度の高いスーパーブロックから順
に、(1)〜(4)の処理を行なうことで、現在処理中のスー
パーブロックの実行頻度は、未処理スーパーブロックの
実行頻度よりも高いことが保証される。これによりリネ
ーム時に生じる可能性のあるコピー命令を、より実行頻
度の低いパスに挿入することが可能になる。また、より
実行頻度の高い実行パスを優先した最適化が可能にな
る。

【００２２】スーパーブロックに対する依存グラフの生
成処理(1)により、命令スケジュールに必要な情報を、
複数の基本ブロックに跨って得ることが可能になる。逆
依存、出力依存エッジの消去処理(2)により、エッジが
切られた命令を、スケジューラが自由に移動することが
可能となり、より効果的なスケジュールが可能になる。
またエッジの消去時に実施する依存エッジ消去可能性検
査により、処理(4)で生じる可能性のあるコピー命令
を、現在の処理中のスーパーブロックよりも、実行頻度
の低いスーパーブロックに挿入できることが保証され
る。

【００２３】命令スケジュール(3)により、基本ブロッ
クを越えた、大域的な命令スケジュールが可能になる。
スケジュール後のリネーム処理(4)により、スケジュー
ル後に順序が逆転した命令、すなわちリネームが必要に
なった変数に対してのみ、リネーム処理を行なうことが
可能になる。またこの処理では、リネーム時にコピー命
令の挿入が必要な場合、このコピー命令をより実行頻度
の低いパスに挿入する。新たに出されたコピー命令は、
本来ある命令と依存しないので、挿入されたスーパーブ
ロックを後にスケジュールすることにより、コピー命令
による影響を最小限に押えたオブジェクトコードを生成
でき、プログラムの高速な実行が可能になる。

【００２４】

【発明の実施の形態】以下、本発明の１実施例を図面を
用いて説明する。

【００２５】図１は、本発明の適用対象である計算機シ
ステムを表す概略構成図である。本発明である変数リネ
ーム方法は、最適化コンパイラに実装され、ディスク装
置１０３もしくは主記憶１０２に格納され、CPU１０１
で実行される。

【００２６】図２は、本発明が実装される最適化コンパ
イラの構成を示している。プログラム２０２は、最適化
コンパイラ２０１へ入力され、例えば図１で示される計
算機で実行されるオブジェクトコード２０６に変換され
る。最適化コンパイラ２０１は、入力されたプログラム
２０２に対して、構文解析２０３などの前処理を行な
い、中間語２０４を生成する。その後、中間語２０４に
対して、最適化処理２０５を行ない、オブジェクトコー
ド２０６を生成する。

【００２７】図３は、最適化処理部２０５内のリネーム
処理部、およびスケジュール処理部の構成を示したもの
である。リネームおよびスケジュール処理３０１は、ス
ケジュール単位に対して呼び出される。以下では、スケ
ジュール単位としてスーパブロックを考える。ここで、
３０１は、スーパーブロックの実行頻度の高い順に呼び
出される。依存グラフ生成部３０２では、与えられたス
ーパーブロック３０６に対する、依存グラフ３０７を生
成する。不要依存エッジ消去部３０３では、依存グラフ
３０７を入力として、３０７から不要な依存エッジを消
去した、依存グラフ３０７を生成する。ここで消去候補
となる依存エッジは、逆依存、出力依存、および制御依
存エッジである。スケジュール部３０４では、依存グラ
フ３０７を入力として、スケジュールを行ない、スケジ
ュールされた命令列である、命令スケジュール３０８を
生成する。最後のリネーム部３０５では、命令スケジュ
ール３０８から、リネームが必要な変数を検出し、それ
らをリネームし、最終的な命令スケジュール３０８を生
成する。また、ここでは、定義点が複数ある場合は、補
償コードとしてコピー命令を生成する。

【００２８】図４は、３０１への入力となるスーパーブ
ロック３０６を示したものである。例えばスーパーブロ
ック４０８は、基本ブロック４０１及び４０２から構成
され、スーパーブロック４０８への制御の入口は、基本
ブロック４０１の先頭ただ１つで、出口は基本ブロック
４０１の末尾及び基本ブロック４０２の末尾の２箇所で
ある。図４では４０８、４０９、４１０、４１１、４１
２がスーパーブロックである。これらのスーパーブロッ
クが実行頻度が高い順に３０１に入力される。

【００２９】以下では、本発明における特徴的な処理で
ある、不要依存エッジ消去部３０３および、リネーム処
理３０５について説明する。

【００３０】図５は、図３における不要依存エッジ消去
部３０３の動作を、PAD図を用いて表したものである。
不要依存エッジ消去部への入力は、図１における、スー
パーブロック３０６に対する依存グラフ３０７である。
まず５０１では、依存グラフ中の全てのノードを辿り、
各ノードをparentとして５０２以下の処理を行なう。５
０２では、parentの全ての子供ノードを辿り、各子供ノ
ードをchildとして、５０３以下の処理を行なう。ここ
で依存グラフ内のノードchildが、ノードparentの子供
であるとは、parentからchildへの何らかの依存があ
り、ノード間に依存エッジが張られていることを表す。
以降の処理は、このノード対(parent,child)に対して行
なう。

【００３１】５０３から５１０では、(parent,child)間
に制御依存エッジの消去可能性を検査する。５１１から
５１６では、(parent,child)間のデータ依存エッジの消
去可能性を検査する。５１７、５１８では、この結果に
基づいて実際のエッジの消去を行なう。

【００３２】まず、５０３では、parentが分岐命令かど
うかを検査する。分岐命令でない場合、(parent,child)
間には制御依存エッジはないので、５１０において(par
ent,child)間の制御依存エッジは消去可能とする。pare
ntが分岐命令ならば、５０４に制御を移す。５０４で
は、childのターゲット変数が、parentの分岐先で生き
ているかどうかを調べる。ここでターゲット変数とは、
命令によって値が定義される変数を表し、変数が生きて
いるとは、実行パス上で、その変数が再定義される前
に、使用があることをいう。childで定義される全ての
ターゲット変数が、parentの全ての分岐先で生きていな
ければ、５０５に制御を移し、parentとｃｈｉｌｄ間の
制御依存エッジは消去可能とする。いずれかのターゲッ
ト変数が、いずれかの分岐先で生きているならば、５０
６以下の処理を行なう。

【００３３】５０６では、図６に示す依存エッジの消去
可能性検出部を呼び出し、制御依存が消去可能かどうか
を検査する。図６の処理は、スーパーブロックの実行頻
度を考慮して、制御依存エッジが消去可能かどうかを決
定する。５０７では、５０６の結果に基づき、制御依存
エッジが消去可能ならば、５０８においてｐａｒｅｎｔ
とchild間の制御依存エッジは消去可能とする。エッジ
が消去不可能ならば、５０９において、parentとchild
間の制御依存エッジは削除不可能とする。以上で(paren
t,child)間の制御依存エッジの消去可能性検査が終了す
る。

【００３４】次に(parent,child)間のデータ依存エッジ
が消去可能かどうかを検査する。５１１では、まずchil
dがparentにフロー依存しているかどうかを検査する。
フロー依存とは、parentで定義するデータをchildで使
用する場合に生じる、消去不可能な依存のことである。
フロー依存しているならば、５１２において、(parent,
child)間のデータ依存エッジは消去不可能とする。フロ
ー依存でない場合、５１３に制御を移す。５１３では、
図６に示すエッジ消去可能性検出部を呼び出すことによ
り、データ依存エッジが消去可能かどうかを検査する。
エッジが消去不可能ならば、５１５において、(parent,
child)間のデータ依存は消去不可能とする。消去可能な
らば、５１６ににおいてデータ依存エッジは、消去可能
とする。以上で(parent,child)間の、データ依存の消去
可能性検査が終了する。

【００３５】最後に、５１７において、(parent,child)
間の制御依存とデータ依存が、共に消去可能かどうかを
検査する。共に消去可能ならば、５１８に制御を移し、
図７に示す依存エッジ消去部を呼び出し、(parent,chil
d)間の依存エッジの消去及び(parent,child)のノード対
の逆転可能リストへの登録処理を行なう。

【００３６】図６は、図５の５０６および５１３から呼
び出される依存エッジ消去可能性検出部の動作を表して
いる。依存エッジ消去可能性検出部では、２つのノード
間の依存エッジを消去できるかどうかを、スーパーブロ
ックの実行頻度に基づいて判定する。

【００３７】６０１では、依存元のノードをparentと
し、６０２では、依存先のノードをchildとする。６０
３では、現在処理しているスーパーブロックをcurrent_
spbとする。６０４では、childのターゲット変数を辿
り、各ターゲット変数をtargetとして、６０５以下の処
理を実行する。６０５では、targetにフロー依存してい
る全ての使用点を辿り、各使用点をuseとして、６０６
以下の処理を実行する。６０６では、useに到達する全
ての定義点を辿り、各定義点をdefとし、６０７以下の
処理を実行する。６０７では、defが所属するスーパー
ブロックをspbとし、６０８では、このspbの実行回数
と、６０３で定義したcurrent_spbの実行回数を比較す
る。spbの実行回数がcurrent_spbの実行回数よりも多け
れば、６０９に制御を移す。６０９では、エッジが消去
不可能であることを呼び側に返し、エッジ消去可能性テ
ストを終了する。

【００３８】６０７、６０８、６０９の処理をuseの全
ての定義点defに対しておこない、全ての定義点で、６
０８の条件が成り立たなければ、６１０に制御を移す。
６１０では、エッジが消去可能であることを呼び側に返
し、エッジ消去可能性テストを終了する。６０８の条件
によって、リネーム時に生成される全てのコピー命令
が、現在処理しているスーパーブロックより実行頻度の
低いスーパーブロックに、出されることが保証される。

【００３９】図７は、５１８から呼び出される依存エッ
ジ消去および逆転可能リストへの登録処理の動作を表
す。この処理でまず７０１で、与えあられた２つのノー
ド間の依存エッジを消去する。次の７０２で、エッジを
消去したノードを、逆転可能リストに登録する。逆転可
能リストとは、エッジを切ることで、スケジュール時
に、順序が逆転する可能性のあるノードを登録したもの
である。このリストは、スケジュール後のリネーム処理
３０５で使用される。

【００４０】図８は、図３のリネーム処理部３０５の動
作を表している。リネーム処理部には、スケジュール済
みの命令列３０８が入力として与えあられる。８０１で
は、５１８で生成した逆転可能リストを辿り、リスト中
の各逆転可能リストノードreversibleに対して、８０２
以下の処理を行なう。ここでreversibleには逆転可能な
依存グラフのノード対が登録されている。８０２では、
reversibleに設定されている、エッジを切る前の依存元
ノードをfirstとし、依存先ノードsecondとする。次に
８０３において、入力された命令スケジュール３０８内
で、firstと、secondの順序が逆転しているかどうかを
検査する。逆転しているならば、first,secondに対し
て、制御依存によるリネーム処理８０４、８０５、８０
６と、データ依存によるリネーム処理８０７、８０８を
施す。

【００４１】８０４では、(first,second)間に制御依存
があるかどうかを検査する。この検査は、reversibleに
設定されている依存クラスを参照することによって行な
う。制御依存があるならば、８０５に制御を移す。firs
tとsecondの間に制御依存があるということは、firstが
分岐命令であることを意味する。８０５では、分岐命令
firstの分岐先の基本ブロックの入口で、secondのター
ゲット変数が生きているかどうかを検査する。いずれか
の分岐先基本ブロックの先頭で、いずれかのターゲット
変数が生きているならば、８０６に制御を移し、second
のターゲット変数に対して、図９に示す１変数のリネー
ム処理を呼び出す。以上で制御依存によるリネーム処理
は終了する。

【００４２】次に、８０７以下の処理により、データ依
存によるリネーム処理を行なう。８０７では、secondの
ターゲットを辿り、各ターゲット変数defに対して、８
０８を実行する。８０８では、defに対して図９に示す
１変数のリネーム処理を呼び出す。以上でデータ依存に
よるリネーム処理は終了する。

【００４３】図９は、８０６、８０８で呼び出される１
変数のリネーム処理の動作を表す。９０１では、現在処
理しているスーパーブロックをspbとし、９０２では、
リネームする変数をdefとする。９０３では、defへの全
ての逆依存、出力依存を消去する。９０４では、defの
リネーム用に新しい変数名new_nameを生成する。９０５
では、defをnew_nameに変更する。以上で定義点のリネ
ームおよび逆依存出力依存の処理は終了する。

【００４４】９０６以下の処理では、defの値を使用す
る変数のリネームを行なう。９０６では、defの使用点
を辿り、各使用点をuseとし、９０７以下の処理を実行
する。９０７では、useの全ての逆依存、出力依存を消
去する。９０８では、useを９０５で生成した新たな変
数new_nameに変更する。以上で、defの使用点のリネー
ムは終了する。

【００４５】最後に、９０９以下で、useの定義点が複
数あるならば、補償コードとしてコピー命令を挿入す
る。９０９では、useの全ての定義点を辿り、各定義点
をdef_2とし、def_2に対して９１０以下の処理を実行す
る。９１０では、defとdef_2が一致するかどうかを検査
する。一致しないならば、９１１に制御を移す。９１１
では、def_2が現在処理しているスーパーブロックspb内
にあるかどうかを検査する。spb内にないならば９１２
に制御を移す。９１２ではdef_2の直後に(new_name = d
ef)なるコピー命令を挿入する。def_2がspb内にあるな
らば、９１３に制御を移す。９１３ではスケジュール済
みのスーパーブロック内で、def_2からdefの間にある全
ての分岐命令の、全ての分岐先基本ブロックを辿り、各
分岐先基本ブロックをbbとし、９１４以下の処理を実行
する。９１４では、def_2がuseの先祖かどうかを検査す
る。ここでdef_2がuseの先祖であるとは、def_2からuse
への実行パスが存在することを意味する。先祖ならば９
１５に制御を移す。９１５では、bbの先頭にコピー命令
(new_name = def)を挿入する。続いて、図１０から図１
７により、以上の変数リネーム処理を簡単な例題に適用
して、その機能と効果を確認する。

【００４６】図１０は、例題プログラムである。図１１
は、図１０を基本ブロックの形で表したものである。１
１０１、１１０２、１１０３、１１０４、１１０５は基
本ブロックを表す。１１０６および１１０７は分岐確率
を表す。図１１は、BB1からBB2への分岐確率が0.9で、B
B3への分岐確率よりも大きいことを表している。

【００４７】図１２は、図１１の基本ブロック１００４
を複写した後のプログラムである。基本ブロック１００
４が複写され、基本ブロック１２０５が新たに生成され
ている。

【００４８】図１３は、図１２からスーパーブロックを
構成した状態を表す。１３０１、１３０２、１３０３は
生成されたスーパーブロックである。スーパーブロック
１３０１は図１２の基本ブロック１２０１、１２０２、
１２０３から生成され、スーパーブロック１３０２は基
本ブロック１２０４、１２０５から生成され、スーパー
ブロック１３０３は１２０６から生成される。図３の、
スケジュールおよびリネーム処理３０１への入力は、こ
れらのスーパーブロックである。処理順序は実行頻度の
高い順で、この例では１３０３、１３０１、１３０２の
順に処理する。以下ではスーパーブロック１３０１の処
理を例に、図３の依存エッジ消去部３０３およびリネー
ム部３０５の処理を説明する。

【００４９】図１４は、図１３のスーパーブロック１３
０１に、図３の依存グラフ生成処理３０２を施したもの
である。１４０１は、スーパーブロック１３０１に対す
る依存グラフを表し、図３の３０７に対応する。依存グ
ラフ１４０１内の各ノードは、１３０１内の各命令に対
応しており、ノード間のエッジは依存を表している。１
４０４と１４０６の間には、変数Yの定義と使用によ
り、フロー依存エッジが張られている。１４０６と１４
０７の間には、変数Yの使用と定義により逆依存エッジ
が張られている。１４０８と１４１２の間には、Xの定
義と使用により、フロー依存エッジが張られている。ま
た１４０９と１４０６、１４０７、１４０８の間には制
御依存エッジが張られている。

【００５０】図１５は、依存グラフ１４０１に、図３の
不要依存エッジ消去処理３０３を施した後の依存グラフ
であり、１５０１は、図３の不要依存エッジを消去し
た、依存グラフ３０７に対応する。

【００５１】不要依存エッジ消去処理における、依存エ
ッジ消去可能性検査の過程を、図１４の逆依存エッジ１
４２０が消去される場合を例に説明する。まず依存先で
ある命令１４０８のターゲット変数Xの定義が到達する
使用点１４１２を考える。これは図６における処理６０
５に対応する。次に１４１２に到達するX定義１４０
８、１４１１が、現在処理しているスーパーブロック１
４０１よりも実行頻度の低いスーパーブロックに含まれ
ているかどうかを検査する。これは図６における処理６
０６、６０７、６０８に対応する。この例では、１４０
８は現在処理しているスーパーブロック１４０１に含ま
れており、１４１１は、スーパーブロック１４０１より
も実行頻度の低いスーパーブロックに含まれている。こ
の結果、処理６１０により、依存エッジ消去候補である
１４２０は消去可能となる。

【００５２】前述の不要依存エッジ消去処理により、図
１４の逆依存エッジ、出力依存エッジ、制御依存エッ
ジ、１４１９、１４２０、１４２３、１４２４、１４２
５、１４２６が、図１５では消去され、図１４で存在し
た１４０６、１４０７、１４０８間のデータ依存による
順序関係は、図で１５はなくなる。また制御依存によっ
て、１４０９と１４０６、１４０７、１４０８の間に存
在した順序関係も、図１５ではなくなる。これにより、
スケジューラが自由に移動できる命令数が増加する。

【００５３】図１６は、１５０１に図３のスケジュール
処理３０４を適用したものである。１６０１は、１３０
１のスケジュール後の命令列である。。１３０１の命令
列と比較すると、１６０１内の命令１６１２と命令１６
１４の順序が逆転している。このため、本来１６１４で
使用されるXの値は、１６１０で定義されたXの値でなけ
ればならないところが、スケジュール後では、１６１２
で定義されたXの値を使用することになっている。正し
い結果を得るために、スケジュール済み命令列１６０１
に対して、図３のリネーム処理３０５を施す必要があ
る。

【００５４】図１７は、１６０１に、リネーム処理を適
用したの結果であり、１７０１は、変数リネーム処理後
の命令スケジュール３０８に対応する。リネーム処理で
は、まず１６１２のターゲット変数Xのリネームを行な
い、新たな名前X1に変更する。この結果が１７１１であ
る。この処理は図９の処理９０５に対応する。次に、１
６１２で定義されたXの値を使用する１６１７のXを、新
たな名前X1に変更する。この結果が１７１７である。こ
れは処理９０８に対応する。次に、１６１７のXに到達
するXの定義を考える。この例では、１６１６と１６１
２が到達する定義である。１６１２で定義されるXは、
すでにX1に変更したので何もしない。１６１６は、現在
処理しているスーパーブロック内にないので、図９の処
理９１２により、１６１６の直後にコピー命令(X1 = X)
を挿入する。これは、９０９以下の処理に対応する。以
上でリネーム処理は終了する。

【００５５】通常のリネームでは、変数を再定義してい
る１７１３の変数Yもリネームしてしまう。しかし、こ
の変数のリネームは、実際のスケジュールには貢献しな
い。すなわちリネームしても実際のスケジュールで、並
列実行するような命令列が生成されない。このように従
来のリネームでは、無駄なリネームを行なうことにな
る。一方本発明では、スケジュールの後に、変数のリネ
ーム処理を行なうことで、図１７に示すように、スケジ
ュールに貢献するリネームだけを行なうことができる。
さらに図１７における１７１１のように、到達する定義
点が複数ある場合でも、リネームを行なっている。これ
により従来のリネームよりも多くの有用な変数をリネー
ムすることができる。複数の定義点がある場合、もとの
ソースプログラム上にないコピー命令１７１６が生成さ
れる。しかしこのコピー命令は、リネーム処理を行なっ
たスーパーブロック１７０１よりも、実行頻度の低いス
ーパーブロック１７０２に挿入され、１７０２に対する
スケジュールはまだ行なっていないため、後で実施され
るスーパーブロック１７０２のスケジュールにより、他
の命令１７１５と共にスケジュールされる。従って、リ
ネームにより生成されるコピー命令によるペナルティー
を低く押えることが出来る。

【００５６】以上の説明から分かるように、図３のスー
パーブロック３０６から、スケジューリングおよびリネ
ーム処理３０１により、命令スケジュール３１０を生成
することができる。

【００５７】

【発明の効果】本発明によれば、スケジューリングに必
要な場合だけ、変数のリネームを行ない、かつ変数の使
用点に到達する定義点が複数ある場合も、スーパーブロ
ックの実行頻度を考慮することにより、少ないペナルテ
ィーのコードを生成することが可能である。これによ
り、より多くの並列性を抽出可能となり、計算機プログ
ラムの実行時間を短縮できる。

【図面の簡単な説明】

【図１】本発明による変数のリネーム方法が実行される
計算機システムの概略構成図。

【図２】本発明による変数のリネーム方法が実装される
最適化コンパイラの概略構成図。

【図３】本発明の変数リネーム方法の概観を与える概要
ブロック図。

【図４】図３の変数リネーム部及びスケジュール部への
入力となるスーパーブロックの概要図。

【図５】図３の変数リネーム方法における、不要な依存
エッジ消去部の動作を表すPAD図。

【図６】図５の不要依存エッジ消去部における、依存エ
ッジ消去可能性検査部の動作を表すPAD図。

【図７】図５の不要依存エッジ消去部における依存エッ
ジ消去部の動作を表すPAD図。

【図８】図３の変数リネーム方法における、変数リネー
ム部の動作を表すPAD図。

【図９】図８の変数リネーム部における、１変数リネー
ム処理の動作を表すPAD図。

【図１０】本発明を具体例を用いて説明するためのソー
スプログラム。

【図１１】図１０のソースプログラムの基本ブロックに
よる表現。

【図１２】図１１における基本ブロックを複写した後の
プログラム。

【図１３】図１２のプログラムのスーパーブロックによ
る表現。

【図１４】図１２のスーパーブロックの依存グラフによ
る表現。

【図１５】図１４の依存グラフから不要依存エッジを消
去した依存グラフ。

【図１６】図１５の依存グラフから得られる命令スケジ
ュール。

【図１７】図１７の命令スケジュールに変数リネームを
施した後の命令スケジュール。

Claims (6)

【特許請求の範囲】
1. 【請求項１】最適化コンパイラおいて変数をリネームす
   る、変数リネーム方法であって、 a)命令スケジュール単位中の複数の命令間のデータ依存
   性と制御依存性を表す、依存グラフを生成するステップ
   と、 b)前記依存グラフを構成する逆依存、出力依存、制御依
   存を表すエッジのなかで、変数をリネームすることによ
   り削除可能な依存エッジを削除し、エッジを削除された
   依存グラフのノード対を、依存エッジ削除ノード対とし
   て登録するステップと、 c)前記不要依存エッジを削除した依存グラフをもとに、
   命令をスケジュールするステップと、 d)前記ステップでスケジュールされた命令列内で、ステ
   ップc)で登録した依存エッジ削除ノード対のうち、順序
   が逆転したものに対して、変数のリネームを行なうステ
   ップと、からなる変数リネーム方法。
2. 【請求項２】請求項１のステップa)への入力となるスケ
   ジュール単位が、基本ブロックすなわちその入口に制御
   が到達すると、基本ブロック中の全ての命令が必ず実行
   されて、基本ブロック出口まで制御が到達する構造であ
   る、請求項１の変数リネーム方法。
3. 【請求項３】請求項１のステップa)への入力となるスケ
   ジュール単位が、スーパーブロックすなわち基本ブロッ
   クのシーケンシャルな列から構成されかつ、そのスーパ
   ーブロックを構成する基本ブロック列へのスーパーブロ
   ック外からの制御の到達は、スーパーブロックの先頭基
   本ブロック一箇所のみでありかつ、スーパーブロック内
   から、スーパーブロック外の基本ブロックへの制御の出
   口を複数持つ構造、である請求項１の変数リネーム方
   法。
4. 【請求項４】請求項１において基本ブロックあるいは、
   スーパーブロックの予測実行頻度を解析し、予測実行頻
   度が高いスケジュール単位から順に処理することを特徴
   とする変数リネーム方法。
5. 【請求項５】請求項１のステップb)における、依存エッ
   ジ削除可能条件を、削除候補エッジが削除され、かつス
   テップ c)の命令スケジュールによって順序が逆転した
   とき、b1)変数のリネームのみが必要で、コピー命令は
   不要な場合、または b2)コピー命令は必要だが、そのコピー命令を現在処理
   しているスケジュール単位よりも実行頻度の低い実行パ
   ス上に出すことができる場合、とする請求項１のリネー
   ム方法。
6. 【請求項６】請求項１のステップb)の依存エッジ削除条
   件を請求項５であたえる条件とする請求項２、あるいは
   請求項３、あるいは請求項４の変数リネーム方法。