JP3280449B2 - コンパイル装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は最適化機能を持つコンパ
イラの最適化効果を促進させるコンパイル装置に関す
る。

【０００２】近年のコンピュータシステムの高速化の要
求に伴い，１サイクルで同時に複数命令を実行できるプ
ロセッサやベクトル演算が可能なマシンが数多く開発さ
れている。それに伴い，最適化コンパイラへの要求が高
まっている。

【０００３】コンパイラは，言語Ａ（例えば，Ｃ言語，
ＦＯＲＴＲＡＮ，ＣＯＢＯＬ等のプログラミング言語）
から，他の言語Ｂ（例えば，アセンブラ言語）へ変換す
るものと考えることができる。一方，コンパイラにおけ
る「最適化」とは，変換後の言語Ｂが，元の言語Ａの意
味を変えずに高機能（実行速度が速い，または必要とす
るメモリ領域を少なくする等）であるように，変換を行
う機能を意味するものとして用いられる。

【０００４】一般に，コンパイラの最適化処理は，プロ
グラムを実行するマシン（コンピュータ，ワークステー
ション等）と独立した中間表現（中間言語，中間テキス
ト，内部表現等と同義）ベースで行われる。つまり，必
要のない中間表現を削除したり，効率的な処理のために
移動したり，同様な処理を共通化することによって，実
際の目的コードの最適化が図られる。従って，中間表現
の選択は，最適化処理の能力や，処理自体にかかるスピ
ードに影響する。しかし，最適化にはさまざまな種類が
存在し，それぞれが，最終目的とするものが異なること
が多いので，ある特定の観点から，中間表現の形態や情
報を固定してしまっては，促進できない最適化が存在す
る。

【０００５】本発明は，プログラミング言語からアセン
ブラ言語（または機械語）に変換する場合の，一般的に
使用されているコンパイラにおける最適化に関するもの
である。

【０００６】

【従来の技術】コンパイルの最適化処理は，上記したよ
うに中間表現を削除したり，移動したり，共通化するこ
とによって実際の目的コードを高速に，またはサイズを
小さくして効率のよいものにすることを目標としてい
る。

【０００７】この中間表現は，言語，マシンにできるだ
け独立に設計することにより最適化やコード生成部の共
通化，部品化を図るのが一般的である。例えば，文献
１：Ａ．Ｖ．エイホ他著「コンパイラ−原理・技法・ツ
ール」サイエンス社発行，文献２：「中間言語の考え
方」，インタフェース，１９８９，Ｍａｒ．ｐ２１１−
２１９に記載されている。

【０００８】図１６は従来の一般的な最適化処理の説明
図である。図中，１００はソースプログラムをコンパイ
ルに適用するための中間表現の形式で保持するフロント
エンド部であり，このフロントエンド部の中間表現は，
最適化部１０１において最適化が施されて，高速化及び
サイズの縮小が行われて，最適化の結果はコード出力部
１０２に供給されると，コード出力部１０２はマシンに
依存したプログラム言語（各マシンに対応するマシン語
等）のコード出力を行う。

【０００９】上記の最適化部１０１で行われる最適化処
理は，言語・マシンに独立な中間表現に対して行うよう
に設計されている。なお，途中で中間表現の構造等を変
化させるコンパイラも存在する，例えば，文献３として
S.S.Muchnick,｀Optimizing Compilers For SPARC’，
Technology,1988 , 文献４としてGhodssi,Vida, S.S. M
uchnick, Alex Wu, ｀A Global Optimizer for Sun FOR
TRAN, C and Pascal', USENIX Conference ,1986 に記
載されている。しかし，これらは主として，コンパイル
時のある部分の処理を既存のもので置き換えるために用
いられる。また，これらは，中間表現のデータ構造の物
理的メモリマップ構造が変化している。

【００１０】また，従来例として特開平２−８１１３７
号公報に，最適化コンパイラの構造に関して開示され，
その目的として，処理効率のよい最適化処理の実現，
最適化の情報収集の処理効率の向上，最適化項目の
検出時間の短縮，原子プログラムの副作用の要因の排
除，原子プログラムの副作用の排除を挙げ，中間語
（中間表現）の変換や最適化をそれぞれ一回ずつ行って
いる。

【００１１】

【発明が解決しようとする課題】上記した従来のよう
に，ある決まった中間表現のまま最適化部を設計し，実
現する方式では，以下のような問題点が存在する。

【００１２】(1)マシン命令と中間表現が１対１に対応
するとは限らないので，命令スケジューリングのように
各マシン命令を何処に持って行くかの判断を行う機能を
コンパイルするような場合，１つの中間表現が複数のマ
シン命令に対応するとマシン命令に依存した最適化を中
間表現により効率的に適用できない。

【００１３】(2)仮に，フロントエンドの出力として，
全ての中間表現をマシン命令と１対１に対応付けて構成
すると，次のような問題が発生する。 ａ．フロントエンドは，一般にターゲット（マシン）
に，無依存に中間表現を作成する。もし，そのようにし
ないと，各ターゲット毎に中間表現が変わるため，コン
パイラを作成するたびに，フロントエンド部分を作成す
る必要が出てくるからである。

【００１４】ｂ．フロントエンドで，命令と中間表現を
１対１にしてしまうと，最適化処理の実現が難しくな
る。まず，中間表現の数が増えるために，最適化処理の
時間がかかるようになる。さらに，処理自体も複雑にな
る。

【００１５】この例として，共通式を認識する場合につ
いて説明する。仮にマシンのアーキテクチュアが，命令
語が３２ビットであり，３２ビットのアドレスを１回で
ロード・ストアできないような場合，ロードやストアの
命令で３２ビットをアドレスする場合，２つの命令を組
み合わせて一つのロードやストアの命令となる。この場
合，フロントエンドで中間表現と命令を１対１に対応さ
せるということは，最適化の処理が，２つの特定の命令
については一つの命令であることを識別する必要があ
る。これは，ロード命令という一つの命令だけを識別す
るだけでは済まないので，処理が複雑になることは明ら
かである。

【００１６】(3)個々の最適化処理は, 決まった中間表
現にのみ適用されることにより, 最適化処理の適用の制
限事項（フロントエンドに対する制限等）が大きくな
る。また，上記の文献３，文献４に記載されたような中
間表現の構造等を変化させる手法は，中間表現のデータ
構造の物理的構造が全く異なるため，最適化処理の共通
化を適用することによる効率が悪い。

【００１７】本発明は，コンパイラに対する多様化する
最適化処理への要求を満たすために，コンパイラがその
ターゲットアーキテクチャと入力ソース及び，それらの
必要な最適化に応じて，高性能のオブジェクトを出力す
ることができるコンパイラ構成方式を提供することを目
的とする。また，中間表現の変換や最適化処理を共通化
してコンパイラ自身を効率化できるコンパイル装置を提
供することを目的とする。

【００１８】

【課題を解決するための手段】図１は本発明の原理的構
成図である。図１において，１はソースプログラム，２
はソースプログラムＳに対応する中間表現を出力するフ
ロントエンド部，３は最適化の構造決定を行う通常の処
理ではオン状態であるスイッチ，４は最適化構造決定手
段，５は最適化手段，６は中間表現変換手段，７は判定
手段，８はコード出力手段，９はオブジェクトプログラ
ムである。なお，最適化構造決定手段４は，コンパイラ
内部または外部に設けることができ，決定した内容は最
適化手段５，中間表現変換手段６に指示される。

【００１９】また，１０は最初のフロントエンドの中間
表現やオブジェクトプログラムを出力するための中間表
現の情報を格納した中間表現データファイル，１１は最
適化構造決定に必要なデータや，決定された最適化情報
を格納する最適化処理データファイル，１２はフロント
エンドの中間表現構造情報，１３は中間表現変換手段６
における変換により発生した中間表現構造情報である。

【００２０】本発明は，最適化構造決定手段によりフロ
ントエンド部のソースレベルとターゲット（マシン）を
元に，最適化の項目とその最適化を実行するのに必要な
中間表現の変換回数を決定し，最適化手段及び中間表現
変換手段によるループ動作を決定した回数を実行して最
適化を行い，必要なら同じ最適化を複数回適用すること
により，各ターゲットや入力ソースに対応した高性能の
オブジェクトを得るものである。

【００２１】

【作用】図１において，コンバイルの対象となるプログ
ラムがフロントエンド部２によって中間表現に変換され
る。スイッチ３は，最適化構造決定手段４における処理
を省略することができるように選択を行うスイッチであ
り，このスイッチ３のオン・オフは最適化レベルまたは
オプションにより決定することができる。

【００２２】このスイッチ３がオフの場合は，入力する
プログラム（ソースプログラム）に対し予め用意された
最適化フェーズ（最適化と中間表現の組み合わせ）の回
数とその処理内容（最適化の内容と中間表現の仕様）
が，最適化手段５と中間表現変換手段６により予め設定
され，その設定された内容により処理を行い，判定手段
７により予め決められた回数の動作後にコード出力手段
８でコード出力が行われてオブジェクトプログラム９が
得られる。

【００２３】スイッチ３がオンになっている場合，この
コンパイラの内部または外部に設けられた最適化構造決
定手段４は，予め供給されるフロントエンドの中間表現
とオブジェクトプログラム（ターゲットマシン）の情報
を中間表現データファイル１０から得て，要求される最
適化の項目（内容）等の最適化情報を最適化処理データ
ファイル１１から得て，最適化と中間表現変換の回数を
決定する。例えば，単純な構造の場合，ソースレベル
（ソースプログラム依存）の最適化と中間表現変換，及
びオブジェクトレベル（ターゲットまたはマシン依存）
の最適化と中間表現変換の合計２回実行するよう決定す
る。

【００２４】最適化構造決定手段４により，最適化の項
目と中間表現の変換回数が決まると，最適化手段５，中
間表現変換手段６及び判定手段７に対して指示が行われ
て最適化動作が実行される。最初はフロントエンド部２
からの中間表現構造情報１２に対して，ソースレベルで
実行される最適化を最適化手段５において実行し，その
結果を中間表現変換手段６により，中間表現の全部また
は一部を変換して中間表現構造情報１３を得る。判定手
段７は最適化構造決定手段４から指示された，回数だけ
ループ動作を実行するよう判断し，最適化手段５，中間
表現変換手段６は各ループにおいてそれぞれ指定された
最適化及び中間表現の変換を行う。

【００２５】判定手段７は予め決められた回数に達した
ことを判定すると，最後に得られた中間表現構造情報１
３（マシン依存の中間表現）をコード出力手段８におい
てコード出力に変換し，オブジェクトプログラム（マシ
ン言語）が得られる。なお，この判定手段７は，最適化
手段５及び中間表現変換手段６のそれぞれが，予め指定
された回数の最適化及び中間表現変換を実行したか否か
を判定する機能を備えることにより実現することがで
き，その場合は判定手段７を別に設ける必要がない。

【００２６】最適化構造決定手段４は，複数回の変換を
指定して，最初の中間表現に対する最適化では適用でき
なかった最適化を後の中間表現に対して適用でき，また
命令スケジューリングを行う場合にも，マシン命令と中
間表現が１対１に対応する段階で実行して，各最適化の
項目に適した中間表現において最適化を施すことができ
るため，コンパイラの最適化の効果を上げることが期待
できる。

【００２７】なお，最適化手段５が，その中に中間表現
変換機能を備える場合は，独立したフェーズとして中間
表現変換手段６を必ずしも別に設ける必要がない。

【００２８】

【実施例】図２は最適化構造決定の処理フローである。
図２には最適化構造決定の処理フローと関連するデータ
を示し，２０はソースプログラムにより作成したフロン
トエンドから出力される中間表現（入力プログラム言語
に依存）の特性（種別）を表すデータ（図１の１０に対
応），２１は最適化終了後にオブジェクトのコードを出
力する機能を持つコード出力部が入力すべき中間表現
（マシン依存）の特性（種別）を表すデータ，２２は最
適化処理の決定に必要なデータ及び決定された最適化及
び中間表現変換のループの回数，それぞれの内容を含む
最適化処理データ（図１の１１に対応）である。

【００２９】図２の処理フローを説明すると，最初に最
適化処理のピックアップが行われる（図２のＳ１），こ
の処理では，最適化コンパイラを作成するためには，そ
のコンパイラが持つべき最適化の項目をピックアップす
る。すなわち，フロントエンドの中間表現，最後のコー
ド出力部へ入力する中間表現を表すデータ２０，２１に
対応して種々の最適化処理の項目が最適化処理データ２
２に予めリストされており，最適化コンパイラによって
実施すべき最適化の対象となる項目が選択される。この
選択はコンパイラ作成者により選択できる。

【００３０】選択された複数の最適化処理の各項目につ
いて，どの段階で実施するかを分類する（図２のＳ
２）。すなわち，各項目が，フロントエンド出力である
中間表現に対して最適化するか，コード出力の前段階で
ある最後の中間表現に対して最適化するか，それらの中
間の段階で最適化するか，またはスケジューリングの段
階か等に分類分けする。この時，次の，の観点に基
づいて分類を行う。

【００３１】最適化を適用する中間表現のデータ構造
の物理的メモリマップ構造の違いに対応して分類する。 適用する最適化が影響するものに対応して分類する。

【００３２】このは，その最適化が言語やプログラム
の構造（ループ構造，条件文等）に依存しているもの
か，ターゲットマシンのアーキテクチャ（並列構造か，
レジスタ構造等）に依存しているものか，両方に有効な
ものかを識別してそれぞれに分類する。分類された結果
は，最適化処理データ２２の中に設定される。

【００３３】次にコンパイラ構造の決定が行われる（図
２のＳ３）。この処理は，２つの段階で構成され，最初
に中間表現の変換回数の決定が行われる（同Ｓ３０）。
この場合，原則的には，上記最適化処理の分類により得
られた分類の個数に対応した変換回数に決定されるが，
他に，中間表現の形態や最適化処理の中間表現の依存条
件により中間表現の変換回数が考慮される。

【００３４】続いて，最適化適用の決定が行われる（同
Ｓ３１）。この最適化適用の決定は次の３つの処理によ
り構成される。最初に，中間表現の形態や中間表現依存
条件に対応して各フェーズにおいて適用可能な最適化を
挙げる（同Ｓ３１０）。次に各項目の適用条件に照らし
て，適用可能なものを絞りこむ（同Ｓ３１１）。最後
に，依存関係（フロントエンドの中間表現に依存か，タ
ーゲットの中間表現に依存か等）により，最適化が実行
される順序を決定する（同Ｓ３１２）。

【００３５】このようにして最適化構造が決定される
と，その決定結果により最適化及び中間表現変換が実行
されて，各フェーズに応じた最適化が行われると共に，
中間表現が変化して，最後に最適化されたオブジェクト
プログラムがコード出力される。

【００３６】次に上記図２に示す最適化構造決定の処理
を図３乃至図６に示す具体例により説明する。この具体
例は，並列ＲＩＳＣ（Reduced Instruction Set Comput
er) 向けのコンパイラである。ＲＩＳＣアーキテクチャ
は，一般にメモリの参照はロード・ストア命令のみが行
うことができ，演算は全てレジスタ間で行うことによっ
てハードウェアの高速化を図っている。並列ＲＩＳＣア
ーキテクチャは，ＲＩＳＣアーキテクチャのうち命令を
同時に複数個実行できる機能をもったものであり，その
ようなアーキテクチャ向けのコンパイラの例について説
明するが，他のあらゆるプロセッサに関しても同様に実
施することができる。また, この具体例では，フロント
エンドはターゲットに関係なく言語毎に一つである，と
いう前提条件がある。この前提条件は，対象となるアー
キテクチャが異なっても，言語自体の仕様は変わらない
ので当然の正当な条件である。

【００３７】図３はコンパイラの入・出力部における中
間表現のデータの例であり，Ａはフロントエンドが出力
する中間表現の集合，Ｂはコード出力のための中間表現
の集合を表し，Ａは入力となるプログラム言語に依存
し，Ｂはターゲットアーキテクチャに依存する。各集合
は上記図２の各データ２０，２１として最適化構造決定
のための既知情報として用意される。

【００３８】図３のＡには，各コード（演算子）に対応
した中間表現の属性が記述され，最初に，フロントエン
ドが出力する中間表現の形態（LINDA という中間表現の
総称名を持つ),次にＬＯＡＤというコード（演算子) ，
データの型（i1〜i4は１乃至４バイトのサインデータ,u
1 〜u4は１乃至４バイトのアン・サインデータ，r8〜r1
6 は８乃至１６バイトの浮動小数点データ，c8〜c32 は
８乃至３２バイトの固定小数点データ），オペランド
（１つ持つ型と２つ持つ型がある），条件としてバウン
ダリ（×は保障しないことを表示），アドレス表現（３
つの値でアドレスを表す）が規定され，以下，コード
（演算子）のＬＯＡＤ，ｃｍｏｖｅ等（他のコードにつ
いては図示省略）について同様なデータが用意される。

【００３９】図３のＢには，ターゲットアーキテクチャ
に依存するコード出力のための中間表現が，Ａと同様の
形式で用意されているが，その内容は必ずしも一致しな
い。例えば，ＬＯＡＤでは，データの型が制限（r16 ，
c8〜c32 は使用できない）され，ｃｍｏｖｅのコードが
無くなっている。

【００４０】この具体例のコンパイラが実現する最適化
処理をピックアップすると，図４に示すようにこの実施
例で実現すべき最適化の項目が得られる。図４におい
て，ＮＯ．１〜ＮＯ．２２の各番号に対し，最適化の名
称が示され，例えば，ＮＯ．１の「CONSTANT FOLDING」
は定数をまとめる最適化（例えば，「１＋３」とあった
ら，「４」として扱う）であり，ＮＯ．２の「CONSTANT
PROPAGATION」は定数を伝播する最適化である，等の各
項目がある。なお，図４のＭＰＡ，ＭＰＢ，ＳＣＨの説
明は後述する。これらの情報も既知情報として，図２の
最適化処理データ２２中に入・出力の中間表現に関する
既知情報と共に，適用される最適化に関する情報を格納
したテーブル（データベース）として格納される。

【００４１】図５はテーブルに格納された最適化情報の
一部の例である。図５にはエントリ番号（図４のＮＯに
対応）１，４，１４，１６，１８及び２２の各情報だけ
示す。エントリ番号１の場合，最適化名はconstant fol
ding (定数をまとめる) という最適化で, 適用する中間
表現の形態，演算子は「＊」と表示され( ＊はDon'tcar
e，すなわち当該最適化の処理では無関係であることを
表す），オペランドはｃｎｔ（定数），中間表現依存条
件，等の各データが設定されている。また，エントリ番
号４の最適化名ＣＳＥ（Common Sub-expression Elimin
ation:共通部分式を除去する最適化）では，中間表現依
存条件の中に，バウンダリについて「×」と表示されて
いる（×は，保障しないことを意味する）。以下，各最
適化の番号（エントリ番号）１４，１６，１８，２２に
関して図５のような情報が作成されている。

【００４２】次に上記図３，図５に示すような情報を基
に図２に示す構造決定の処理フローが実行される。な
お，フロントエンドが出力する中間表現の集合ａとコー
ド出力のための中間表現の集合ｂが，全て一致した場合
は，中間表現の変更は不要であるが，図３の例のように
一致しない場合は，図２に示す構造決定の処理が行われ
る。

【００４３】この例では，最適化の項目が上記図４のよ
うにピックアップされ（図２のＳ１の処理），それぞれ
の最適化処理を上記図２の最適化処理の分類（図２のＳ
２）について説明した，の観点に従って分類する。
この具体例では，後述するように，中間表現のデータ構
造の物理的メモリマップ構造を同じにしているため，上
記の観点での分類は行う必要が無い。については，
言語及びプログラム構造に依存している最適化とは，最
適化が実施される項目が，入力するプログラムの構造や
変数であるようなものである。またアーキテクチャに依
存した最適化とは，実際のターゲットとなるマシンのア
ーキテクチャの仕様を意識した最適化である。

【００４４】メモリアドレッシング関連の命令は，レジ
スタ割り付けや，命令スケジューリング等に代表される
が，アーキテクチャによって異なるので，これらの命令
に関する最適化もアーキテクチャ依存の最適化に属す
る。この実施例では，アーキテクチャ依存の最適化を更
に２つに分類した。すなわち，イ．命令数を減らす，よ
り高速の命令に変更する等（例えば，乗算を加算の繰り
返しに変更する等），命令自体を出力するまたは出力し
ないに関する最適化ロ．命令の出力する順序に関する最
適化上記したことを基準にして，図４の番号１〜２２の
各最適化の項目について分類すると，図４の右側に示す
ＭＰＡ，ＭＰＢ，ＳＣＨに分類される。ここで，ＭＰＡ
は言語依存（ソースプログラム言語に依存）の最適化で
あり，ＭＰＡの欄に○が付されている最適化の項目は，
言語依存の最適化として実施されることを示す。

【００４５】ＭＰＢはアーキテクチャ依存（ターゲット
マシンのマシン命令）の最適化であり，ＭＰＢに○が付
された最適化の項目は命令の出力に関連する最適化とし
て実施する。ＳＣＨに○が付された最適化は，アーキテ
クチャ依存の最適化の内，命令実行順序に関する最適化
として実行するものである。なお，図４の中で，複数の
分類で○が付された最適化は，同じような最適化を，異
なった中間表現をターゲットとして複数回実行すること
を意味している。

【００４６】上記のように，分類が行われると，次にコ
ンパイラ構造の決定が行われる（図２のＳ３）。ここ
で，最初に中間表現を何回変更するか決定する（図２の
Ｓ３０），各最適化処理テーブル（図５参照）の中間表
現の形態の種類と中間表現依存条件の場合の数の組み合
わせで求められる。すなわち，中間表現の形態は，「LI
NDA 」という１種類であり，中間表現依存条件の場合の
数は，無関係を表す「＊」が付された要素を除外する
と，「バウンダリ」に関して，次の２つのパターンがあ
る。

【００４７】 バウンダリ：bxd , axd アドレス ２ （フェー
ズ３とする） バウンダリ：× アドレス ２ （フェー
ズ２とする） これと，フロントエンド時の出力である バウンダリ：× アドレス ３ （フェー
ズ１とする） を合わせて，全部で３形式必要であることが分かる。

【００４８】次に，どの最適化をどこで，いつ適用する
か設定する（図２のＳ３１）。ここでは，最適化処理テ
ーブル（図５）の中間表現の形態，及び中間表現依存条
件から，フェーズ１，フェーズ２，フェーズ３で適用可
能な最適化を選ぶ（図２の３１０）。この図５の各最適
化の項目（エントリ番号）については，次のように選択
できる。なお，１，４，１４・・の各数字はエントリ番
号を表す。

【００４９】フェーズ１：１，４，１４，１６ フェーズ２：１，４，１４，１６，１８ フェーズ３：２２ 次に上記により選択された中から，適用条件に照らし
て，適用を絞りこみ（図２の３１１），次のようにな
る。

【００５０】フェーズ１：１，４，１４，１６ フェーズ２：１，４，１８ フェーズ３：２２ 次に依存関係から，各最適化の実行順序を決定する（図
２の３１２）。

【００５１】フェーズ１：１４，（１，４），１６ ；
但し，（１，４）は何れを先に行っても良いことを意味
する。 フェーズ２：（１，４），１８ フェーズ３：２２ このようにしてこの具体例における，最適化構造が決定
される。この決定による最適化及び中間表現の変更の処
理は自動化される。自動化した場合に備えるデータは次
のようなものである。

【００５２】１）各テーブルの項目を要素として持った
データ構造を定義する。 ２）各データは，記号化（文字列または番号化）するこ
とにより，コンパイラの内部構造として持つ。

【００５３】図６に中間表現の変換を行うためのテーブ
ルと最適化処理のテーブルのデータ構造を示す。Ａ．は
中間表現のテーブルであり，「ＩＭＬ」は中間表現を意
味し，中間表現形態（IML-TYPE) ，演算コード(CODE-TY
PE),型のリスト, オペランドのリスト等の各項目が定義
される。Ｂ．は最適化処理のテーブルの構造であり，最
適化番号，最適化名，中間表現の形態，適用演算子リス
ト等の各項目が定義される。なお，これらのデータは，
図１に示す構成において，最適化処理データファイル１
１に格納される。

【００５４】次に本発明の実施例を図７乃至図１５を用
いて説明する。図７は実施例のコンパイラの構成図であ
る。このコンパイラの構成は，上記，図２に示す最適化
構造決定のフローにより以下のように決定された結果得
られる。

【００５５】上記図３乃至図６に示す並列ＲＩＳＣ向け
のプログラムに関するコンパイラの最適化構造が決定さ
れることにより，最適化コンパイラの構造が決定され，
これに基づいて，図７に示す実施例の最適化コンパイラ
の構成が得られる。

【００５６】図７の構成では，最適化の数はフェーズ１
乃至フェーズ３（各フェーズは上記図４のＭＰＡ，ＭＰ
Ｂ及びＳＣＨの各分類に対応する）の３回であり，中間
表現の変換が３回行われる。但し，最初の変換は，ソー
スプログラムからフロントエンドにより最初の中間表現
に変換することであるから，その後２回の中間表現の変
換が行われる。

【００５７】図７において，フロントエンド７０の後に
はソースプログラムレベルの中間表現（これを１回目の
中間表現とする）が格納されている。このフロントエン
ド７０の後の中間表現に対し，７１で示す最適化Ａが実
行される。この最適化処理Ａは図４の分類ＭＰＡ（フェ
ーズ１）に属する各最適化の項目について実行される。
この後，ＩＥ (Interface Expansion)１で示す中間表現
変換７２で２回目の中間表現の変換が行われる。この変
換でターゲット命令レベルの最適化用の中間表現に変換
され，この中間表現に対し７３で示す最適化Ｂが実行さ
れる。

【００５８】この最適化Ｂでは，図４の分類ＭＰＢ（フ
ェーズ２）に属する各最適化が実行され，その結果に対
し次にＩＥ２で示す３回目の中間表現変換７４が行われ
る。この変換で命令スケジューリング用の中間表現が得
られ，この中間表現に対し命令スケジューリング７５が
実行される。この命令スケジューリング７５では，上記
図４の分類ＳＣＨ（フェーズ３）の最適化（図４の番号
２２）が実行され，その結果はコード出力７６の処理が
実行される。

【００５９】この実施例では，フロントエンドの出力を
上記に示したように第１回目の中間表現とした。フロン
トエンドは，一般にターゲットに無依存に中間表現を作
成する。もし，そのようにしないと，各ターゲット毎に
中間表現が変わるため，コンパイラを作成するたびに，
フロントエンド部分を作成する必要があるからである。

【００６０】図７の構成に対し，新規に最適化の項目を
追加する場合，または最適化の仕様が変更になった時
は，図２に示す最適化構造決定の処理フローのＳ１〜Ｓ
３で示すステップを繰り返して，コンパイラの構造を決
定すればよい。これにより，最適化の分類が増加する場
合には，新たに，中間表現を変更する部分を設けること
により高性能なオブジェクトを出力するためのコンパイ
ラの構造を得ることができる。

【００６１】上記図２による最適化構造決定は，外部か
ら選択等の入力設定により実現することもできるが，上
記図６のように最適化処理の仕様をテーブルに登録して
おくことにより，条件に合う最適化処理を取り出すよう
にして自動化することができる。この場合，最適化構造
決定の処理が不用となり，コンパイラの構成は，図１の
構成においてスイッチ３がオフに設定された状態に対応
する。

【００６２】また，最適化処理の決定において，複数の
候補を選び，それぞれについて最適化処理を独立して行
い，その中から最適なものを選ぶことによって，高性能
オブジェクトを得ることができる。

【００６３】また，複数の最適化構成候補に対してそれ
ぞれ独立に最適化効果処理を行う場合は，プロセッサ
が複数ある時は，各プロセッサにそれぞれの最適化処理
をアサインする。一つのプロセッサで行う時は，コー
ド出力の直前から，最適化にループする。ループの回数
は候補の数でもある。各候補について，結果の中間表現
列をリストにして格納しておく。

【００６４】上記のリスト要素（各場合の中間表現列）
に対して，実行時間を見積もり，最短のものをコード化
する。実行時間の見積もりは，各中間テキストに対応す
る命令が分かるのでその命令の実行時間がわかる（これ
は，命令スケジューリング時に必要なアーキテクチャ情
報である）。ループに関しては，ループの数が静的に分
かっている場合は，その数だけ掛け算をする。分からな
い場合は，同じ定数を掛ければ，どのコードも条件は同
じなので，大きく誤ることはない。

【００６５】また，図２の処理を一つのコンパイラフェ
ーズとして，コンパイラ内部に持つことにより，入力プ
ログラムに応じて最適化処理の適用を制御することがで
きる。

【００６６】上記実施例（図７）に対する付加機能につ
いて説明する。上記図７の実施例では，フロントエンド
の出力は，最適化及び中間表現変換の各処理を通過する
ようになっているが，各フェーズにおける各最適化処理
を実行するか否かを切替える選択スイッチ（図１のスイ
ッチ３と異なる）を，各最適化処理及び中間表現変換処
理の前段に設ける。この選択スイッチは，コンパイラの
外部から操作することにより任意のフェーズの任意の最
適化を止めるように切替えられる。このような，機能を
コンパイラのオプションとして備え，そのオプションが
立っていると，その最適化をパスする（リターンす
る）。これにより，翻訳時間の短縮や，コンパイラ作成
時のデバッグを効率的化する。

【００６７】更に，上記実施例（図７）の構成に対し，
中間表現をプリントする処理を付加することができる。
すなわち，各フェーズにおける中間表現をプリント機能
に対し出力してプリントアウトするか否かを選択する選
択スイッチを設ける。この選択スイッチは，上記各フェ
ーズにおける最適化処理を実行するか否かを選択する選
択スイッチと異なる。この中間表現のプリント機能を，
プログラムのデバッグまたはコンパイラの処理中に，オ
プション制御により呼び出すことにより，任意のフェー
ズの任意の場所における中間表現を出力することがで
き，デバッグ効率を向上することができる。

【００６８】次に上記，図７に示すコンパイラの構成を
用いた具体的なプログラムの例に対する各最適化のフェ
ーズにおける中間表現の例を図８乃至図１５に示す。図
８は実施例のコンパイラの動作を説明するためのプログ
ラム例，図９は実施例のプログラム例に対するフロント
エンドの出力，図１０は実施例のプログラム例に対する
最適化Ａ後の出力，図１１及び図１２は実施例のプログ
ラム例に対する中間表現変換（ＩＥ１）後の中間表現，
図１３及び図１４は実施例のプログラム例に対する最適
化Ｂ後の出力である。

【００６９】ここで，図９乃至図１５に記述された幾つ
かの主要な符号について説明する。Slabel-n(0＜＝n)
は，基本ブロックを示し，そのブロックを構成する中間
テキストが，それ以下に羅列される。

【００７０】各中間テキストは，「演算子（オペレー
タ） オペランドの並び」というように表現され，オペ
ランドとオペレータの間は空白で区切られている。各オ
ペランドに関して説明すると，以下の通りである。

【００７１】var ：変数 std,prg ：コンパイラが生成する一時変数 axd,bxd ：配列，構造体データ cnt ：定数 図８に示すプログラム（ソースプログラム）例に対して
フロントエンド終了後に，中間表現として図９に示すよ
うなフロントエンド出力が発生する。このフロントエン
ドの出力は，完全に命令と中間表現が１対１に対応して
なく，この状態では最適化処理が不十分な状態である。

【００７２】このフロントエンドの出力に対して，最適
化Ａ（図７の７１）において，図４のＭＰＡの欄に○が
付された各項目の最適化が実行される。この最適化Ａ後
の出力は図１０のようになる。図９と図１０を参照する
と最適化の効果が分かる。すなわち，この中間表現形態
では，例えば，変数XXや，配列要素dd(i) 等は，それら
を一まとまりとして扱うことができることが分かる。ま
た，構造体の代入に関しては，１つの中間表現で実現さ
れている。

【００７３】次に，最適化Ａの出力（図１０）は次にＩ
Ｅ１（図７の７２）において，中間表現が変換されて図
１１，図１２に示す中間表現が得られる。このＩＥ１で
は，最適化Ａの結果得られる中間表現をターゲットの命
令セット及び次に行われる最適化Ｂ（図７の７３）の最
適化機能に応じて変換し，ＩＥ１の目的は，最適化Ｂの
対象となるものを，中間表現として明確に表すことであ
る。

【００７４】図１１，図１２に示すように，それまで，
ＸＸとかｄｄ（ｉ）というように表現されていたもの
が，そのアドレッシングに応じて，中間表現の数が増え
たり，オペランドの表現が変換していることが示されて
いる。また，構造体の代入文は，ループ構造になってい
ることも示されている。さらに，ＩＥ１の変換の実現に
関しては，入力された中間表現のコードとオペランドが
決まれば，出力は一意に決まるので，テーブル分岐の手
法を用いることによって実現できる。これ以外の方法を
利用しても良い。

【００７５】次に図１１，図１２に示す，ＩＥ１の出力
に対して最適化Ｂ（図７の７３）が実行される。この最
適化Ｂで行う最適化の対象は，ソース上では直接現れな
かったり，フロントエンドでは解析しなかったターゲッ
トに依存した部分であるが，図４に示すように上記最適
化Ａと重なる部分が含まれている。また，この実施例で
は，例えば，以下の項目も最適化Ｂの対象となる。

【００７６】１．アドレス計算に関する最適化 ２．構造体の代入のループ処理 この実施例では，基本的には最適化Ｂの機能は，最適化
Ａと同じである。従って，最適化Ｂは最適化Ａで仕様し
た同じ関数をできる限り呼ぶようにして実現する。その
ためには，中間表現の形態について考慮し，また，最適
化を繰り返し施すことについての説明は後述する。

【００７７】以上のことから，従来例のように，最適化
Ｂのフェーズが存在しない場合，上記の各項目に関する
最適化が行われないことになり，ターゲットがＲＩＳＣ
アーキテクチャのような場合は，高性能なオブジェクト
を得られないことになる。従って，ＩＥ１（図７の７
２）及び最適化Ｂのフェーズは，必須の処理である。最
適化Ｂによって，最適化された結果を図１３，図１４に
示す。図１１，１２のＩＥ１の中間表現の出力と図１
３，図１４の最適化Ｂの出力を参照すると，基本的な最
適化がＩＥ１の後に施されたことが分かる。

【００７８】他の実施例：上記の実施例（図７）の構成
では最適化Ａの各関数と最適化Ｂの各関数の共通化を図
っているが，それぞれ別個のものとして実現する他の実
施例を構成することができる。

【００７９】図７の実施例では，ＩＥ１（図７の７２）
の中間表現変換のフェーズにおいて，完全に命令と中間
表現を１対１にしていない。これは，ＩＥ１のフェーズ
以降の処理を，その機能や利用する情報によって，次の
ように大きく２つに分けることができるからである。

【００８０】 最適化Ｂ，レジスタ割り付け 命令スケジューリング は，次に示すように，その目的が命令の出力に関する
ものである。

【００８１】ａ．余分な命令を消去する。ｂ．重複して
いるものをまとめる。ｃ．より高速な命令に変更する。 これにより，は命令が出る／出ないということより
も，１つ１つの命令の順序を意識して，ハードウェアの
効率化を図ることを主たる目的にしている。従って，次
に示すように，ＩＥ１の中間表現変換の直後で，命令を
１対１にしない方が，コンパイラの構成上，優れてい
る。

【００８２】すなわち，命令スケジューリングでは，例
えば，倍精度の load/store を２つの単精度命令に分け
ることが必要である。なぜならば，これらの load/stor
e を並列に実行できるために，連続させて実行させるよ
りも，離して実行させた方が，早く命令が終了するから
である。しかし，レジスタ割り付けや最適化を考えた場
合，もともとこのデータは１つの実体を指しているた
め，これを分離して扱うことは，最適化Ａに関して上記
したようにコンパイラの処理を複雑にするだけである。
その上，レジスタ割り付けを考えると，連続したレジス
タを割り当てる必要のあるデータが２つに分離されてし
まうことになり，レジスタ割り付けのために「データが
連続している」という何らかの情報を持つ必要が出てく
る。

【００８３】一方，ＩＥ２（図７の中間表現変換７４）
は，命令スケジューリングに対応するために，中間表現
と実際の命令を１対１に分解する。この実現方式はＩＥ
１（図７の７２）と同じである。

【００８４】この実施例における命令スケジューリング
は，レジスタ割り付け後に，命令スケジューリングを行
う。命令スケジューリングの技法は，公知の方法を用い
る。また，この他の実施例では，命令スケジューリング
をレジスタ割り付け後に位置付けたが，次の１〜４のよ
うに配置しても良い。なお，これらのどの場合も，命令
スケジューリングの前に，命令と中間表現を１対１に対
応させることを意識することにより，中間表現をどのよ
うに変換するか（命令スケジューリングをどのタイミン
グで行うか）を決定することができる。

【００８５】 １．レジスタ割り付けの前に命令スケジューリング ２．命令スケジューリングとレジスタ割り付けを同時に
行う。 ３．レジスタ割り付けと命令スケジューリングを任意の
順序で繰り返す。

【００８６】４．レジスタ割り付けと命令スケジューリ
ングを任意の順序で繰り返し，その間に最適化を行う。 次に中間表現の形態について説明する。この実施例では
中間表現は図１５に示すようなデータ構造を持つ。図１
５を実際にプログラム化する時は，構造体宣言を次のよ
うにすることにより, この部分を可変化することがで
き, オペランドの数は, 演算子によって可変にすること
ができる。

【００８７】struct OperandType operand[1]; 以上によって，中間表現の物理的メモリマップ構造をコ
ンパイラのフェーズ間で固定して扱うことが可能とな
る。

【００８８】この実施例では，中間表現の変換は，次の
１．〜３．のような内容を意味する。なお，以下の説明
において，「言（げん）」という表現を用いるが，
「言」とは中間表現のうち命令に相当するものを意味す
る。例えば，図９の#label-2において, move var:("1") cnt: 0 bqe #label-9 var:("1") var:("n") という部分があるが，「move var:("1") cnt: 0 」が１
つの言を表す。ここで，moveは演算子（または，言コー
ド）といい，var:("1") はオペランド１（第１オペラン
ド），cnt: 0はオペランド２（第２オペランド）とい
う。

【００８９】１．中間表現がポイントしているオペラン
ドを変更する。この例は，図８〜図１４において，言の
オペランドの変化により示されている。これはポインタ
の付け換えだけの処理により行われる。上記，図９の例
により言のオペランドの変更を説明すると，図９（フロ
ントエンド後の出力）のラベル２（#label-2）の「move
var:("1") cnt: 0 」が，図１０（最適化Ａ後の出
力）の#label-2では，「move prg:#17cddc("1") cnt:0
」と変化している。

【００９０】２．中間表現のオペレータを変更する。 ３．中間表現の出力方法を変える。これは１つの言から
複数の言になったり，ループ構造になったりすることで
ある。この例は, 図９，図１０までは cmoveで表すされ
た部分が，図１１（ＩＥ１後の中間表現），図１３（最
適化Ｂ後の出力）では，ラベル１４(#label-14) のルー
プになっている。

【００９１】以上を行うことによって，中間表現のデー
タ構造を変化させることなく，しかし意図している意味
の変更を行うことが可能となる。次に最適化の繰り返し
について説明する。

【００９２】この実施例では，最適化フェーズで，同じ
ような最適化を行うことができるようにするため，上記
したように，最適化の対象となる中間表現の物理表現を
統一させる。そして，現在の処理フェーズを覚えておく
ための変数を使用することにより，個々の最適化ルーチ
ンの共通化を実現する。

【００９３】また，これらの最適化は，同一フェーズの
中でも，これらの各最適化を繰り返し呼び出すことがで
きる。この呼び出しに関しては，以下の方法が考えられ
る。 １．コンパイラ作成者がコンパイラ作成時に判断する。

【００９４】２．中間表現の変更があったか否かのフラ
グ（初期値はオフ）を設け，最適化処理において，中間
表現の変更があった場合は，これをオンにする。このフ
ラグがオンである間，フラグを初期化して最適化処理を
トライする。

【００９５】３．回数を決めて（コンパイラ作成者が決
定するか，オプションで外から与える），最適化を繰り
返す。 ４．以上１〜３の方式を組み合わせる。

【００９６】という方法を用いることができる。この実
施例では，上記１の方法を用いているが，最適化レベル
に応じて，上記１〜４の最適化繰り返しを実現するよう
にし，ユーザが最適化レベルで切り分けることができる
ようにしても良い。

【００９７】

【発明の効果】あるアーキテクチャに対して本発明によ
る最適化コンパイラにより，コンパイラの構造を決め
て，その構成に従って最適化を行うようにすれば，ソー
スプログラムの特性や，アーキテクチャの特徴を意識し
た最適化を，好適な位置で適用できるので，高性能のオ
ブジェクトを得ることができる。

【００９８】また，最適化をコンパイラのフェーズの流
れの中で繰り返し適用することが可能となり，高性能の
オブジェクトを得ることができる。さらに，同じ最適化
処理や，中間表現変換処理を，各部で適用するのでコン
パイラ自身の処理効率が向上する。

【図面の簡単な説明】

【図１】本発明の原理構成図である。

【図２】最適化構造決定の処理フローである。

【図３】コンパイラの入・出力部における中間表現のデ
ータ例である。

【図４】実施例で実現すべき最適化の項目と分類を示す
図である。

【図５】テーブルに格納された最適化情報の一部の例で
ある。

【図６】中間表現の変換を行うためのテーブルと最適化
処理のテーブルのデータ構造を示す図である。

【図７】実施例のコンパイラの構成図である。

【図８】実施例のコンパイラの動作を説明するためのプ
ログラム例である。

【図９】実施例のプログラム例に対するフロントエンド
の出力である。

【図１０】実施例のプログラム例に対する最適化Ａ後の
出力である。

【図１１】実施例のプログラム例に対する中間表現変換
（ＩＥ１）後の中間表現（その１）である。

【図１２】実施例のプログラム例に対する中間表現変換
（ＩＥ１）後の中間表現（その２）である。

【図１３】実施例のプログラム例に対する最適化Ｂ後の
出力（その１）である。

【図１４】実施例のプログラム例に対する最適化Ｂ後の
出力（その２）である。

【図１５】中間表現のデータ構造の説明図である。

【図１６】従来例の一般的な最適化処理の説明図であ
る。

【符号の説明】

１ ソースプログラム ２ フロントエンド部 ３ スイッチ ４ 最適化構造決定手段 ５ 最適化手段 ６ 中間表現変換手段 ７ 判定手段 ８ コード出力手段 ９ オブジェクトプログラム 10 中間表現データファイル 11 最適化処理データファイル 12,13 中間表現構造情報

───────────────────────────────────────────────────── フロントページの続き (72)発明者 堀田 耕一郎 神奈川県川崎市中原区上小田中1015番地 富士通株式会社内 (56)参考文献 特開 昭62−163146（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/45

Claims (3)

(57)【特許請求の範囲】
1. 【請求項１】 ソースプログラムに基づき中間表現を出
   力するフロントエンド部と， 中間表現に対し最適化を施す最適化手段と， 最適化により得られた結果に対し中間表現の形式を変換
   する一段以上の中間表現変換手段と， 最後に得られた中間表現をコード出力するコード出力手
   段と， 前記最適化手段と中間表現変換手段による最適化フェー
   ズの繰り返し回数と各フェーズにおける最適化の処理内
   容を決定する最適化構造決定手段とを有し， 前記最適化構造決定手段により決定された内容に基づい
   て各最適化フェーズと共に中間表現の形式を変更して最
   適化を行うことを特徴とするコンパイル装置。
2. 【請求項２】 請求項１において， 上記最適化構造決定手段は，フロントエンド部の出力す
   るプログラムに依存する中間表現及び対象となるアーキ
   テクチャに依存する中間表現及び適用される最適化の項
   目に基づいて，中間表現の形式を変化させる回数及び各
   フェーズで適用する最適化処理を決定することを特徴と
   するコンパイル装置。
3. 【請求項３】 請求項１または２において， 前記最適化処理及び中間表現変換における中間表現を管
   理するためのデータの主要部分についてはメモリ上のデ
   ータ構造を固定的なものとし， 該データ構造により 中間表現の変換処理及び最適化を共
   通化することを特徴とするコンパイル装置。