JP2006139413A

JP2006139413A - プログラム、プログラムコードの合理化方法、プログラムコードの生成方法、プログラムコード、及び情報処理装置

Info

Publication number: JP2006139413A
Application number: JP2004326878A
Authority: JP
Inventors: 志泰 ▲高▼畠; Yukiyasu Takahata
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-11-10
Filing date: 2004-11-10
Publication date: 2006-06-01
Also published as: US20060107258A1

Abstract

【課題】プログラムコードの一部分において手続きにまたがる最適化を行なうことを可能とする。
【解決手段】複数のルーチンを含んで構成されるプログラムコードを記憶する情報処理装置に、前記プログラムコードを構成する各ルーチンのうち、他のルーチンから呼び出される各ルーチンについて、それぞれの複製を生成する手順と、前記プログラムコードを構成する各ルーチン及び各複製に含まれる、他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換える手順と、前記プログラムコードを構成する各複製に含まれる各命令語を、前記各複製を呼び出すルーチン又は複製によりそれぞれ実現される情報処理を合理化するようにそれぞれ書き換える手順と、を実行させるためのプログラムに関する。
【選択図】図３

Description

本発明は、プログラム、プログラムコードの合理化方法、プログラムコードの生成方法、プログラムコード、及び情報処理装置に関する。

コンピュータに情報処理を実行させるためには、コンピュータに実行させる命令語の集合であるプログラムコードを作成しなければならない。このプログラムコードは、通常Ｃ言語やＦＯＲＴＲＡＮ等のいわゆる高級言語を用いてソースコードとして作成される。そしてその後ソースコードは、コンパイラによりコンピュータが実行可能なオブジェクトコードに変換される。またさらに、コンパイラによって生成される複数のオブジェクトコードをリンカにより一つにまとめて、コンピュータによる実行が可能なプログラムコードに変換される場合もある。この場合、リンカにより生成されるコンピュータ実行可能なプログラムコードを、コンパイラにより生成されるオブジェクトコードと区別して実行コードと呼ぶ場合もある。

またコンパイラやリンカによりプログラムコードの変換が行われる際に、いわゆる最適化と呼ばれる処理が行われる場合がある。最適化とは、プログラムコードにより実現される情報処理がより合理的にコンピュータに実行されるようにプログラムコードを書き換えることをいう。例えば、ＣＰＵ（Central Processing Unit）からメインメモリへのデータの読み書きの頻度を減らすために、ＣＰＵにメインメモリへのデータの読み書きを行わせるロード命令やストア命令を減らすようにプログラムコードを書き変えたり、ＣＰＵにより分岐命令が実行される頻度を減らすために、ループ処理部分を展開するループアンローリングを行ったりする。プログラムコードを最適化することにより、情報処理をより短時間に実行することが可能となったり、情報処理を実行するために必要なメモリの使用量を減らすことができたりする。

さらに、プログラムコードが複数のルーチン（例えば手続きや関数）を含んで構成されている場合には、最適化は各ルーチンの内部においてそれぞれ行われるのみならず、他のルーチンとの関連においても行われる場合がある（例えば非特許文献１、及び非特許文献２参照）。

例えば非特許文献１には、複数のルーチンにまたがる最適化（以降、手続き間最適化とも記す）を静的に行なう場合に、プログラムコード全体を構成する手続き（または関数）全てに対して手続き間最適化を適用する技術が開示されている（以降、手続きや関数等のルーチンを手続きとも記す）。

また非特許文献２には、ＪＡＶＡ（登録商標）で記述されたプログラムコードを動的にコンパイルするJITコンパイラにおいて、実行時に手続きの呼び出し関係を解析し手続き間最適化を行ない、その呼び出し関係が続く間は同じ実行コード実行するが、呼び出し関係が変わる時に再コンパイルを行ない、手続き間最適化を再び行なう技術が開示されている。
Mary W. Hall, Brian R. Murphy, Saman P. Amarasinghe, Shih-Wei Liao, Monica S. Lam, "Interprocedural Analysis for Parallelizaion", Proceedings of the 8th Internatioanl Workshop on Languages and Compilers for Parallel Computing(LCPC95), 1995. Vugranam C. Sreedhar, Michael Burke, Jong-Deok Choi, " A framework for interprocedural optimization in the presence of dynamic class loading", Conference on Programming Language Design and Implementation, pp.196-207, 2000.

従来の手続き間最適化はプログラムコード全体に対して行なわれるため、プログラムコードが大規模な場合、コンパイルに長時間を要し、またコンパイルに必要なメモリ量も膨大になる。

ところが、プログラムコードの一部分（以降、部分プログラムコードと呼ぶ）のみに対して手続き間最適化を行おうとしても、手続き間最適化を行おうとする部分プログラムコードに含まれる手続きが、手続き間最適化を行わない部分プログラムコードに含まれる手続きから呼び出される場合には、部分プログラムコードに対する手続き間最適化を行うことはできない。手続き間最適化を行うことによって、部分プログラムコードは書きかえられてしまうからである。

また、部分プログラムコードだけで手続き間最適化を行なおうとすると、手続きの呼び出し関係が不正確になり、ある手続きは、その手続きがどの手続きから呼び出されるかが不明確になってしまう。すなわち、呼び出し元の手続きの情報が不正確になる。この場合、手続き間最適化が適用できなくなる。

本発明は上記課題を鑑みてなされたものであり、部分プログラムコードに対する手続き間最適化を可能とするプログラム、プログラムコードの合理化方法、プログラムコードの生成方法、プログラムコード、及び情報処理装置を提供することを主たる目的とする。

上記課題を解決するために、本発明は、複数のルーチンを含んで構成されるプログラムコードを記憶する情報処理装置に、前記プログラムコードを構成する各ルーチンのうち、他のルーチンから呼び出される各ルーチンについて、それぞれの複製を生成する手順と、前記プログラムコードを構成する各ルーチン及び各複製に含まれる、他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換える手順と、前記プログラムコードを構成する各複製に含まれる各命令語を、前記各複製を呼び出すルーチン又は複製によりそれぞれ実現される情報処理を合理化するようにそれぞれ書き換える手順と、を実行させるためのプログラムに関する。

その他、本願が開示する課題、及びその解決方法は、発明を実施するための最良の形態の欄、及び図面により明らかにされる。

部分プログラムコードに対する手続き間最適化が可能になり、プログラムコード全体に対して手続き間最適化を行なう場合と比べて、コンパイル時間や使用メモリ量を減らすことができる。

＝＝＝情報処理装置の構成＝＝＝
本実施の形態に係る情報処理装置２００を図１に示す。情報処理装置２００は、ＣＰＵ２１０、主記憶装置２２０、ポート２３０、記録媒体読取装置２４０、入力装置２５０、出力装置２６０、外部記憶装置２８０を備えて構成される。

ＣＰＵ２１０は情報処理装置２００の全体の制御を司るもので、外部記憶装置２８０に記憶される本実施の形態に係る各種の動作を行うためのコードから構成されるコード変換プログラム８００をオペレーティングシステム８１０による制御の下で実行することにより、本実施の形態に係る情報処理装置２００としての各種機能を実現する。例えばＣＰＵ２１０によりコード変換プログラム８２０やオペレーティングシステム８１０が実行され、主記憶装置２２０やポート２３０、記録媒体読取装置２４０、入力装置２５０、出力装置２６０、外部記憶装置２８０等のハードウェア機器と協働することにより、プログラムコード記憶部や複製ルーチン生成部、呼び出し命令変更部、最適化実行部が実現される。

主記憶装置２２０は例えば半導体記憶装置により構成することができる。主記憶装置２２０は、ＣＰＵ２１０によりワークエリアとして用いられる他、コールグラフ７００、中間語７１０、手続間解析情報７２０、呼出し手続きリスト７３０を記憶する。これらの詳細については後述する。

記録媒体読取装置２４０は、記録媒体２７０に記録されているプログラムやデータを読み取るための装置である。読み取られたプログラムやデータは主記憶装置２２０や外部記憶装置２８０に格納される。従って、例えば記録媒体２４０に記録されたコード変換プログラム８００を上記記録媒体２４０から読み取って、主記憶装置２２０や外部記憶装置２８０に記憶するようにすることができる。

記録媒体２４０としてはフレキシブルディスクや磁気テープ、コンパクトディスク等を用いることができる。記録媒体読取装置２４０は情報処理装置２００に内蔵されている形態とすることもできるし、外付されている形態とすることもできる。
外部記憶装置２８０は、例えばハードディスク装置や半導体記憶装置等とすることができる。外部記憶装置２８０には、コード変換プログラム８００、オペレーティングシステム８１０、ソースコード９００、オブジェクトコード９１０、実行コード９２０、ヘッダファイル９３０、オブジェクトコードライブラリ９４０が記憶される。
入力装置２５０は情報処理装置２００へのデータ入力等のために用いられる装置でありユーザインタフェースとして機能する。入力装置２５０としては例えばキーボードやマウス等を用いることができる。
出力装置２６０は情報を外部に出力するための装置でありユーザインタフェースとして機能する。出力装置２６０としては例えばディスプレイやプリンタ等を用いることができる。
ポート２３０は通信を行うための装置である。例えばネットワークを介して他の情報処理装置と通信を行うことができる。そしてこの場合例えば、コード変換プログラム８００を、ポート２３０を通じて他の情報処理装置からネットワークを介して受信して、主記憶装置２２０や外部記憶装置２８０に記憶するようにすることもできる。

ソースコード９００は、Ｃ言語やＦＯＲＴＲＡＮ等の高級言語で記述されたプログラムコードである。オブジェクトコード９１０は、コード変換プログラム８００によりソースコード９００から生成される、情報処理装置２００が実行可能なプログラムコードである。この場合コード変換プログラム８００はコンパイラとして機能する。実行コード９２０は、複数のオブジェクトコード９１０からコード変換プログラム８００により生成される、情報処理装置２００が実行可能なプログラムコードである。この場合コード変換プログラム８００はリンカとして機能する。

オブジェクトコードライブラリ９４０は、いくつかの手続きを集合させ、オブジェクトコード９１０として構成したものである。オブジェクトコードライブラリ９４０に含まれる手続きを使用する他のオブジェクトコード９１０とオブジェクトコードライブラリ９４０とをリンクさせて実行コード９２０を生成するようにすることにより、オブジェクトコードライブラリ９４０に含まれる手続きの作成の手間を省くことが出来るので、プログラムコードの開発効率を向上させることができる。
ヘッダファイル９３０は、オブジェクトコードライブラリ９４０に含まれる手続きのうち、他のオブジェクトコード９１０から呼び出される手続きを示す情報を記載したプログラムコードである。

図２にコンパイル及びリンクの手順を示す。まずコンパイラ８０１（つまりコード変換プログラム８００）にソースコード９００が入力されるとオブジェクトコード９１０が生成される。そしてリンカ８０２（つまりコード変換プログラム８００）にオブジェクトコード９１０が入力されると実行コード９２０が生成される。

オブジェクトコード９１０には、中間コードなどの各種手続き間最適化用の情報が含まれている。また、そのためにコンパイラ８０１は手続き間最適化用の情報を含んだオブジェクトコード９１０を生成する。コンパイラ８０１は、複数のソースコード９００を入力とすることができるが、makeコマンドなどのツールを利用する場合は、１つのソースコード９００を入力し、１つのオブジェクトコード９１０を生成する。

リンカ８０２は、プログラムコードを構成する全てのオブジェクトコード９１０を入力とするため、リンカ８０２では、プログラムコードを構成する全ての手続きがそろう。従来の手続き間最適化は、このリンカ８０２で実施されている。本実施の形態では、部分的に手続き間最適化を行なうことができるので、コンパイラ８０１、または、リンカ８０２のいずれにおいても手続き間最適化を実施することができる。

＝＝＝コンパイラ、リンカの構成＝＝＝
まず、手続き間最適化を行なうコンパイラ８０１の構成図を図３に示す。
図３に示すように、手続き間最適化を行なうコンパイラ８０１は、入力されたソースコード９００に基づいてオブジェクトコード９１０を生成する。オブジェクトコード９１０を生成する際には、適宜、中間語７１０やコールグラフ７００、手続き間解析情報７２０を主記憶装置２２０に出力し、またそれらを利用しながら処理を進めてゆく。

コンパイラ８０１は、中間語生成部、コールグラフ作成部、手続き間最適化用コールグラフ処理部、手続き内解析部、手続き内解析情報の手続き間伝播部、手続き間最適化部、手続き内最適化部を備える。
中間語生成部は、ソースコード９００を入力とし中間語７１０を生成する。

コールグラフ作成部は、中間語７１０を入力とし、手続きの呼び出し関係をコールグラフ７００として作成する。コールグラフ７００とは、プログラムコードに含まれる各手続きをノードとして各ノード間を有向矢印で結合したものである。矢印は、他の手続きを呼ぶ手続きを示すノードから、その手続きに呼ばれる手続きを示すノードに向かう向きで表される。

手続き間最適化用コールグラフ処理部は、中間語７１０とコールグラフ７００を入力とし、手続きをクローニングし、コールグラフ７００を更新する。ここでクローニングとは、手続きの複製を生成することを言う。詳細は後述する。

手続き内解析部は、中間語７１０を入力とし、手続き内における手続き間最適化に必要な情報を解析し、手続き間解析情報７２０を出力する。手続き間解析情報７２０は、手続き間最適化に必要な情報が記憶されたテーブルである。例えば手続き内解析部においては、他の手続きを呼び出す場合の実引数の値が手続き間解析情報７２０に出力される。

手続き内解析情報の手続き間伝播部は、コールグラフ７００と手続き間解析情報７２０を入力とし、コールグラフ７００のエッジをたどりながら手続き間解析情報７２０を更新していく。例えば、手続きを呼び出す時の実引数の値を呼び出される手続の仮引数の値として手続き間解析情報７２０に記憶してゆく。

手続き間最適化部は、手続き間解析情報７２０とコールグラフ７００を入力とし、手続き間最適化を行ない、中間語７１０を更新する。つまり、クローニングにより生成された各手続きの複製に含まれる各命令語を、各複製を呼び出す手続き又はその複製によりそれぞれ実現される情報処理を合理化するようにそれぞれ書き換える。

手続き内最適化部は、手続き間で最適化された中間語７１０を入力とし、手続き内の解析を行ない、手続き内の最適化を実施し、中間語７１０を更新する。そしてオブジェクトコード９１０を出力する。

ここで、中間語生成部、コールグラフ作成部、手続き内解析部、手続き内情報の手続き間伝播部、手続き間最適化部、手続き内最適化部は、従来の手続き間最適化コンパイラと同様である。本実施の形態においては、手続き間最適化用コールグラフ処理部により、部分プログラムコードに対しても手続き間解析が行なえるように処理を行なう。

なお、手続き間最適化を行わずにソースコード９００をコンパイルすることも可能である。その場合は、中間語生成部の処理を行った後、手続き内最適化部による処理を行って、オブジェクトコード９１０を生成する。手続き間最適化を行うか行わないかの指定は、例えば情報処理装置２００のオペレータが入力装置２５０からコンパイル実行コマンドを入力する際に行うことができる。

ここで、手続き間最適化を実施する場合の例を、図４乃至図７を参照しながら説明する。手続き間最適化として手続き間定数伝播の例を示す。

まず図４（ａ）において、ソースコード９００では、手続きSUB0は３行目で手続きSUB1を呼び出している。このとき、実引数に５が使われている。呼び出し先の手続きSUB1では、５行目で仮引数としてIが使われている。このソースコード９００に手続き間定数伝播を適用すると、図４（ｂ）の６行目のように、SUB1において、Iの値を５に変換することができる。そして、SUB1に手続き内の最適化を適用することにより、図４（ｂ）の６行目のIF文の条件式“５＜２０”が常に真になるので、このIF文を削除することができる。そして図４（ｃ）のようにソースコード９００を最適化することができる。この場合のコールグラフ７００を図５に示す。

手続きSUB0とSUB1がソースコード９００の全体であれば、上記のような最適化は有効である。ところが、手続きSUB0とSUB1が部分プログラムコードであり、手続き間最適化を適用しない他の部分プログラムコードに手続きSUB2があるとすれば、手続きSUB2が手続きSUB1を呼び出す可能性がある。また、手続きSUB2が手続きSUB1を呼び出すときに、Iの値が5以外である可能性もある。しかし、手続きSUB2は手続き間最適化対象外なので、手続きSUB1を呼び出すか否かは不明である。もし呼び出すと仮定してもIの値は解析できない。このまま、手続きSUB0とSUB1の間で手続き間最適化を適用し、手続きSUB1がI=5で最適化されると、SUB2がI=5以外の値でSUB1を呼び出した場合には、プログラムコード作成者の意に反する動作をする可能性がある。この様子を示すコールグラフ７００を図６に示す。

このように、部分プログラムコードに手続き間最適化を行なおうとしても、手続き間最適化対象外の手続きが手続き間最適化対象の手続きを呼び出すか否かが不明なため、手続き間最適化はできない。

そこで本実施の形態においては、図７に示すように手続きのクローニングを行う。プログラムコード全体を構成する手続きはSUB0、SUB1、SUB2の３つであり、このうち部分プログラムコードを構成する手続きSUB0及びSUB1に対して手続き間最適化を適用する場合を示す。本実施の形態では、手続きSUB1に対して手続きのクローニングを行ない、手続きSUB1’を生成する。そして、手続きSUB0は手続きSUB1ではなく手続きSUB1’を呼び出すようにする。このようにすると、手続きSUB1’は手続きSUB2からは呼び出される可能性がなくなる。すなわち、不明な呼び出し元手続きがなくなるので、手続きSUB0と手続きSUB1’の間でI=5の手続き間定数伝播を適用することができるようになる。そして手続きSUB2は、何らの変更なく手続きSUB1を呼び出せば良いのである。

次に手続き間最適化を行なうリンカ８０２の構成図を図８に示す。
図８に示すように、手続き間最適化を行なうリンカ８０２は、入力されたオブジェクトコード９１０に基づいて実行コード９２０を生成する。実行コード９２０を生成する際には、適宜、中間語７１０やコールグラフ７００、手続き間解析情報７２０を主記憶装置２２０に出力し、またそれらを利用しながら処理を進めてゆく。このことはコンパイラ８０１の場合と同様である。

リンカ８０２は、コンパイラ８０１と同様に、中間語生成部、コールグラフ作成部、手続き間最適化用コールグラフ処理部、手続き内解析部、手続き内解析情報の手続き間伝播部、手続き間最適化部、手続き内最適化部を備える。そしてリンカ８０２はさらにリンク部を備える。リンク部は、複数のオブジェクトコード９１０を結合させて一つの実行コード９２０を生成する処理を行う。

＜実施例１＞
実施例１では、コンパイラ８０１、あるいはリンカ８０２における手続き間最適化方法について述べる。ここではコンパイラ８０１の場合を例に説明する。

まず図３の手続き間最適化用コールグラフ処理の、実施例１におけるアルゴリズムを図９に示す。
まず、STARTから始まり、S1000においてコールグラフ７００に含まれる全ての手続きに対象に、それぞれの手続きに対して、S1010以降の処理を行なうようにする。ここでは、S1010から一連の処理を行なう対象の手続きをｆとする。

S1010では、現在処理中の手続きｆがMAIN関数か否かを調べる。MAIN関数であれば他の手続きから呼び出されることはないため、クローニングする必要はない。そのため、S1000へ戻り次の手続きに対する処理を行う。一方、MAIN関数でない場合にはクローニングする必要がある可能性が有るためS1020へ進む。ここでMAIN関数とは、プログラムコードを構成する各ルーチンの中で、他のどの関数からも呼び出されることのない関数をいう。MAIN関数はメインルーチンと呼ばれることもある。

S1020では、手続きｆに呼び出し元手続きがあるか、つまり、手続きｆが他の手続きから呼び出されることがあるか否かを調べる。呼び出し元の有無は、コールグラフ７００を調べることでわかる。すなわち、コールグラフ７００で手続きｆに入力エッジがあれば、手続きｆに対して呼び出し元が存在する。呼び出し元があればS1030へ進み、なければS1000へ戻る。

S1030では、手続きｆに対してクローニングを行ない、新しく手続きｆ’を生成する。そして、手続きfの呼び出し元の手続きは、手続きｆ’を呼び出すように変更する。これは、手続きfの呼び出し元の手続きに含まれる、手続きｆを呼び出す命令語を、手続きｆ'を呼び出す命令語に書き変えることにより行うことができる。そして、S1000へ戻る。S1000で処理する手続きがなくなった場合は、ENDへ進む。

図１０はプログラムコードの例であり、プログラムコード全体は、手続きA,B,C,D,Xからなる。そして、手続きA,B,C,Dを含む部分プログラムコードへ手続き間最適化を適用し、手続きXを含む部分プログラムコードへは手続き間最適化を適用しない場合を示す。手続き間最適化対象となる手続きA,B,C,Dは、図１１に示すようなコールグラフ７００になる。また手続きXは、手続き間最適化対象外なので、コールグラフ７００には含まれない。

図１０に示したプログラムコードに対して図９に示したアルゴリズムを適用した場合について具体的に説明する。
まず、図９のS1000で手続きAを処理の対象とすると、S1010で手続きAはMAIN関数でないのでS1020へ進み、S1020では呼び出し元手続きがないのでS1000へ戻り、手続きAについては、なにもしないで終了する。
次に、手続きBがS1000で処理の対象となり、S1010で手続きBはMAIN関数でないのでS1020へ進み、S1020では呼び出し元手続きに手続きAがあるのでS1030へ進む。S1030では手続きBに対してクローニングを適用し、新たに手続きB’を生成する。そして、手続きAは手続きB’を呼び出すように変更する。
手続きC、Dに対しても、手続きBと同様に処理され（S1000〜S1030）、それぞれ手続きC’、D’が生成される。

この結果、コールグラフ７００は図１２に示すように変更される。手続きB’,C’,D’はクローニングにより生成された手続きである。手続きB,C,Dは、手続きXから呼び出されるか否かが不明であるため、呼び出し元との手続き間最適化は行なえない。しかし、手続きB’,C’,D’は、呼び出し元に不明なものはないので、手続き間最適化が行なえる。具体的には、手続きAとB’、AとC’、B’とD’、C’とD’、BとD’,CとD’の間でそれぞれ手続き間最適化を行なうことができるようになる。

＜実施例２＞
次に実施例２について説明する。実施例２においては、手続き間最適化対象のプログラムコード（第1のプログラムコード）に含まれる、他の手続きから呼び出される各手続きのうち、手続き間最適化対象外のプログラムコード（第２のプログラムコード）に含まれる手続きからも呼び出される手続きに対して、クローニングを行う。

図１３にリンク時における部分的なプログラムコードの手続き間最適化方法の実施例を示す。図８に示したリンカ８０２を図１３に示すように拡張し手続き間最適化を行なう。
リンカ８０２には、手続き間最適化を適用するオブジェクトコード９１０と、手続き間最適化を適用しないオブジェクトコード９１０とが入力される。各オブジェクトコード９１０の区別は、オブジェクトコード９１０内の手続き間最適化用情報の有無で判別する。

リンカ８０２は、手続き間最適化を適用しないオブジェクトコード９１０に対して、そのオブジェクトコード９１０内に参照（手続きの呼出し命令）はあるが定義のない手続きを調べ、その手続き名を呼び出し手続きリスト７３０へ出力する。つまり、そのプログラムコード９１０を構成する各手続きに含まれる各命令語のうち、そのプログラムコード９１０を構成しない手続きを呼び出す命令語にそれぞれ含まれる、そのプログラムコード９１０を構成しない手続きを示す情報（例えば手続き名）を、手続きリスト７３０へ出力する。この処理は、呼び出し手続き名の出力処理部により行われる。
そして手続き間最適化用コールグラフ処理部は、手続き間最適化を適用するオブジェクトコード９１０に含まれる各手続きのうち、手続き呼び出しリスト７３０に記載された情報により示される各手続きをクローニングする。

以下に、図１３に示したリンカ８０２を用いて、図１０に示したプログラムコードに対して手続き間最適化を行った場合について説明する。ここでは、図１０のプログラムコードで手続きXが手続きCを呼び出すと仮定する。その場合のプログラムコードを図１５に示す。

呼び出し手続き名の出力処理部では、手続き間最適化を適用しないオブジェクトコード９１０に対して、例えばUNIX（登録商標）のnmコマンド等を用いて未定義の手続きを検出することができる。そしてこの手続き名を、呼び出し手続きリスト７３０に出力する。図１０のプログラムコードでは、オブジェクトコード９１０中の手続きXからCを呼び出しているため、手続きCの参照が存在するが、手続きCの定義は存在しないので、未定義の手続きCが検出され、呼び出し手続きリスト７３０へ手続き名“C”が出力される。

手続き間最適化用コールグラフ処理部は、コールグラフ７００の情報と、呼び出し手続きリスト７３０の情報を利用して、手続きのクローニングを行う。
そして最後にオブジェクトコード９１０をリンクでリンクし、実行コード９２０を出力する。

図１４にリンク時における部分的な手続き間最適化方法のアルゴリズムを示す。
S2000では、コールグラフ７００に含まれる全ての手続きを対象に、それぞれの手続きに対してS2010からの処理を行なうようにする。S2010からの一連の処理を行なうときの手続きをｆとする。
S2010では、処理中の手続きｆがMAIN関数か否かを調べ、MAIN関数ならS2000へ戻る。MAIN関数でなければS2020へ進む。
S2020では、手続きｆが手続き間最適化対象プログラムコード内に呼び出し元手続きがあるかを調べ、なければS2000へ戻る。あればS2030へ進む。
S2030では、図１３で調べた呼び出し手続きリスト７３０があるか否かを調べ、あればS2050へ進み、なければS2040へ進む。
S2050では、呼出し手続きリスト７３０内に手続きｆの手続き名があるか否かを調べ、あれば、S2040へ進み、なければS2000へ戻る。

S2040では、手続きｆに対してクローニングを行ない、新しく手続きｆ’を生成する。そして、手続きfの呼び出し元の手続きは、手続きｆ’を呼び出すように変更する。これは、手続きfの呼び出し元の手続きに含まれる、手続きｆを呼び出す命令語を、手続きｆ'を呼び出す命令語に書き変えることにより行うことができる。そして、S2000へ戻る。S2000で処理する手続きがなくなった場合は、ENDへ進む。

なおS2030において、呼び出し手続きリスト７３０がない場合にS2040に進むのは、呼出し手続きリスト７３０がなければ、手続き間最適化対象外のプログラムコードからその手続きが呼び出されるか否かの判別が出来ないからである。このためS2040に進んで、その手続きのクローニングを行うようにしている。

以下に図１０、図１５のプログラムへ図１４のアルゴリズムを適用した場合を示す。
まず、図１４のS2000で手続きAを処理の対象とすると、S2010で手続きAはMAIN関数でないのでS2020へ進み、S2020では呼び出し元手続きがないのでS2000へ戻り、手続きAについては、なにもしないで終了する。
手続きBは、S2010ではMAIN関数でなく、S2020では呼び出し元手続きとして手続きAがあり、S2030では呼び出し元手続きリスト７３０があるので、S2050へ進む。S2050では呼び出し手続きリスト７３０に手続きBは無いのでS2000へ戻る。
手続きCに対しては、S2010でMAIN関数でなく、S2020では呼び出し元手続きとして手続きAがあり、S2030では呼び出し手続きリスト７３０があるので、S2050へ進む。S2050では呼び出し手続きリスト７３０に手続き名“C”があるので、S2040へ進み、クローニングの処理を行なう。
手続きDに関しては、S2010ではMAIN関数でなく、S2020では呼び出し元手続きとして手続きB及びCがあり、S2030では呼び出し元手続きリスト７３０があるので、S2050へ進む。S2050では呼び出し手続きリスト７３０に手続きDは無いのでS2000へ戻る。

この結果、コールグラフ７００は図１６のようになる。手続きB,Dには手続き間最適化対象外からの呼び出しがないので、不明な呼び出し元がなく、そのため手続きのクローニングが適用されない。手続きCには手続き間最適化対象外からの呼び出しがあるのでクローニングが適用されている。このように呼び出し元を調べることにより、実施例１の場合と比べて、手続きB,Dのクローニングがなくなり、無駄なクローニングを行なわないようにすることができる。

＜実施例３＞
次に、コンパイル実行時あるいはリンク実行時にオペレータにより入力されるオプションを用いて、部分プログラムコードに対して手続き間最適化を行なう場合について説明する。

図１７には、手続き間最適化対象外からの呼び出しがあるというオプション（プログラムコードを構成する各手続きのうち、複製を生成する手続きを指定する情報）、および、手続き間最適化対象外からの呼び出しがないというオプション（プログラムコードを構成する各手続きのうち、複製を生成しない手続きを指定する情報）の具体例をそれぞれ示す。

図１７に示す、手続き間最適化対象外からの呼び出しがあるというオプションは、手続き間最適化対象外からの呼び出しがある手続きとしてCを指定するものである。図１７に示す、手続き間最適化対象外からの呼び出しがないというオプション。手続き間最適化対象外からの呼び出しがない手続きとしてB,Dを指定するものである。

図１８にこれらのオプションを用いて部分プログラムコードに対する手続き間最適化を行なう場合のアルゴリズムを示す。

S3000では、コールグラフ７００に含まれる全ての手続きを対象に、それぞれの手続きに対してS3010からの処理を行なうようにする。S3010からの一連の処理を行なうときの手続きをｆとする。
S3010では、処理中の手続きｆがMAIN関数か否かを調べ、MAIN関数ならS3000へ戻る。MAIN関数でなければS3020へ進む。
S3020では、手続き間最適化対象プログラムコードに含まれる手続きの中で、手続きfを呼び出している呼び出し元関数があるかを調べ、なければS3000へ戻る。あればS3030へ進む。
S3030では、手続き間最適化対象外からの呼び出しなしオプションがあるか否かを調べ、あればS3060へ進み、なければS3040へ進む。
S3060では、手続きｆが手続き間最適化対象外からの呼び出しなしオプションの中にあるか否かを調べ、あればS3000へ戻り、なければS3050へ進む。
S3040では、手続き間最適化対象外からの呼び出しありオプションがあるか否かを調べ、あればS3070へ進み、なければS3050へ進む。
S3070では、手続きｆが手続き間最適化対象外からの呼び出しありオプションの中にあるか否かを調べ、あればS3050へ進み、なければS3000へ戻る。

S3050では、手続きｆに対してクローニングを行ない、新しく手続きｆ’を生成する。そして、手続きfの呼び出し元の手続きは、手続きｆ’を呼び出すように変更する。これは、手続きfの呼び出し元の手続きに含まれる、手続きｆを呼び出す命令語を、手続きｆ'を呼び出す命令語に書き変えることにより行うことができる。そして、S3000へ戻る。S3000で処理する手続きがなくなった場合は、ENDへ進む。

なおS3030及びS3040において、いずれも”NO”の場合、すなわちオプションの入力がない場合にS3050に進むのは、オプションの入力がなければ、手続き間最適化対象外のプログラムコードからその手続きが呼び出されるか否かの判別が出来ないからである。このためS3050に進んで、その手続きのクローニングを行うようにしている。

以下に図１０、図１５のプログラムに対して図１７のコンパイルオプションの「-called_by_noipo:C」（手続き間最適化対象外からの呼び出しありオプション）を指定し、図１８のアルゴリズムを適用した場合について説明する。

まず、図１８のS3000で手続きAを処理の対象とすると、S3010で手続きAはMAIN関数でないのでS3020へ進み、S3020では呼び出し元手続きがないのでS3000へ戻り、手続きAについては、なにもしないで終了する。
手続きBは、S3010ではMAIN関数でなく、S3020では呼び出し元手続きとして手続きAがあり、S3030では手続き間最適化対象外からの手続きなしオプションはないのでS3040へ進む。S3040では、手続き間最適化対象外からの呼び出しありオプションがあるのでS3070へ進む。S3070では、手続き間最適化対象外からの呼び出しありオプションに手続きBがないのでS3000へ戻る。
手続きCは、S3010ではMAIN関数でなく、S3020では呼び出し元手続きとして手続きAがあり、S3030では手続き間最適化対象外からの手続きなしオプションはないのでS3040へ進む。S3040では、手続き間最適化対象外からの呼び出しありオプションがあるのでS3070へ進む。S3070では、手続き間最適化対象外からの呼び出しありオプションに手続きCが含まれているので、S3050へ進む。S3050では、クローニングなどの処理が行なわれる。
手続きDは、S3010ではMAIN関数でなく、S3020では呼び出し元手続きとして手続きB,Cがあり、S3030では手続き間最適化対象外からの手続きなしオプションはないのでS3040へ進む。S3040では、手続き間最適化対象外からの呼び出しありオプションがあるのでS3070へ進む。S3070では、手続き間最適化対象外からの呼び出しありオプションに手続きDがないのでS3000へ戻る。

この結果、図１６のようなコールグラフ７００になり、実施例２と同じような手続き間最適化ができる。つまり、手続きB,Dには手続き間最適化対象外からの呼び出しがないので、不明な呼び出し元がなく、そのため手続きのクローニングが適用されない。手続きCには手続き間最適化対象外からの呼び出しがあるのでクローニングが適用されている。このように呼び出し元を調べることにより、実施例１の場合と比べて、手続きB,Dのクローニングがなくなり、無駄なクローニングを行なわないようにすることができる。

＜実施例４＞
次に、ソースコード９００の中にコンパイラ指示文を記述することにより、コンパイル時、又はリンク時に部分プログラムコードに対して手続き間最適化を行なう場合の例を説明する。

ソースコード９００中にコンパイラ指示文を記述することにより、手続き間最適化対象外のプログラムコードに含まれる手続きから手続きの呼び出しがなされていることを示す例を図１９に示す。図１９中の９行目の「!$called_by_noipo」がコンパイラ指示文である。コンパイラ８０１は、このコンパイラ指示文により、図１９の１０行目から１２行目に定義されている手続きCが、手続き間最適化対象外のプログラムコードに含まれる手続きから呼び出されることを検知することができる。

図２０に、コンパイラ指示文を用いた部分プログラムコードに対する手続き間最適化を行なう場合のアルゴリズムを示す。
まずS4000では、コールグラフ７００に含まれる全ての手続きを対象に、それぞれの手続きに対してS4010からの処理を行なうようにする。S4010からの一連の処理を行なうときの手続きをｆとする。
S4010では、処理中の手続きｆがMAIN関数か否かを調べ、MAIN関数ならS4000へ戻る。MAIN関数でなければS4020へ進む。
S4020では、手続き間最適化対象プログラムコードに含まれる手続きのうち、手続きｆを呼び出す関数があるかを調べ、なければS4000へ戻る。あればS4030へ進む。
S4030では、手続きｆに対して手続き間最適化対象外からの呼び出しのコンパイラ指示文があるかを調べ、コンパイラ指示文があればS4040へ進み、指示文がなければS4000へ戻る。

S4040では、手続きｆに対してクローニングを行ない、新しく手続きｆ’を生成する。そして、手続きfの呼び出し元の手続きは、手続きｆ’を呼び出すように変更する。これは、手続きfの呼び出し元の手続きに含まれる、手続きｆを呼び出す命令語を、手続きｆ'を呼び出す命令語に書き変えることにより行うことができる。そして、S4000へ戻る。S4000で処理する手続きがなくなった場合は、ENDへ進む。

以下に図１９のプログラムコードに対して図２０のアルゴリズムを適用した場合の例を示す。
まず、図２０のS4000で手続きAを処理の対象とすると、S4010で手続きAはMAIN関数でないのでS4020へ進み、S4020では呼び出し元手続きがないのでS4000へ戻り、手続きAについては、なにもしないで終了する。
手続きBは、S4010ではMAIN関数でなく、S4020では呼び出し元手続きとして手続きAがあり、S4030では、コンパイラ指示文により手続きBに対しては手続き間最適化対象外からの呼び出しがないのでS4000へ戻る。
手続きCは、S4010ではMAIN関数でなく、S4020では呼び出し元手続きとして手続きAがあり、S4030では、コンパイラ指示文により手続きCに対しては手続き間最適化対象外からの呼び出しがあるのでS4040進む。S4040では、クローニングなどの処理が行なわれる。
手続きDは、S4010ではMAIN関数でなく、S4020では呼び出し元手続きとして手続きB,Cがあり、S4030では、コンパイラ指示文により手続きDに対しては手続き間最適化対象外からの呼び出しがないのでS4000へ戻る。

＜実施例５＞
次に、ライブラリ（オブジェクトコードライブラリ９４０、第１のプログラムコード）をコンパイルするときの手続き間最適化の適用例を以下に示す。つまりライブラリ９４０に対して手続き間最適化を適用する場合の例を示す。

図１０の手続きA,B,C,Dを含むプログラムコードがライブラリ９４０を構成するプログラムコード（第１のプログラムコード）であり、手続きXを含むプログラムコードがライブラリ９４０を使用するプログラムコード（第２のプログラムコード）であると仮定する。そして図１０において、手続きXが手続きAとCを呼び出していると仮定する。この様子を図２１に示す。

通常、ライブラリ９４０を使用するときは、そのライブラリ９４０を使用するプログラムコード内にヘッダファイル９３０をインクルードする。ヘッダファイル９３０には、ライブラリ９４０を構成する各手続きのうち、ライブラリ９４０を使用するプログラムコードを構成する手続きから呼び出される手続きを示す情報（例えば手続き名）が含まれている。そのため、ライブラリ９４０を構成するプログラムコードの中に含まれる手続きがヘッダファイル９３０内に記載されていない場合には、その手続きに対する手続き間解析対象外からの呼び出しはないものとして処理することができる。またライブラリ９４０を構成するプログラムコードの中に含まれる手続きがヘッダファイル９３０内に記載されている場合には、その手続きに対する手続き間解析対象外からの呼び出しがあるものとして処理することができる。
ここでは、図２１に示すように、手続きAとCがヘッダファイルで宣言されていると仮定する。

図２２にライブラリ９４０に対して手続き間最適化を適用する場合のアルゴリズムを示す。
S5000では、コールグラフ７００に含まれる全ての手続きを対象に、それぞれの手続きに対してS5010からの処理を行なうようにする。S5010からの一連の処理を行なうときの手続きをｆとする。

S5010では、処理中の手続きｆがMAIN関数か否かを調べ、MAIN関数ならS5000へ戻る。MAIN関数でなければS5020へ進む。
S5020では、手続き間最適化対象プログラムコードに含まれる手続きのうち、手続きｆを呼び出す関数があるかを調べ、なければS5000へ戻る。あればS5030へ進む。
S5030では、ヘッダファイル９３０があるか否かを調べ、ヘッダファイル９３０があればS5050へ進み、ヘッダファイル９３０がなければS5040へ進む。
S5050では、手続きｆがヘッダファイル９３０内で宣言されているか否かを調べ、宣言されていればS5040へ進み、宣言されていなければS5000へ戻る。

S5040では、手続きｆに対してクローニングを行ない、新しく手続きｆ’を生成する。そして、手続きfの呼び出し元の手続きは、手続きｆ’を呼び出すように変更する。これは、手続きfの呼び出し元の手続きに含まれる、手続きｆを呼び出す命令語を、手続きｆ'を呼び出す命令語に書き変えることにより行うことができる。そして、S5000へ戻る。S5000で処理する手続きがなくなった場合は、ENDへ進む。

なおS5030において、ヘッダファイル９３０がない場合にS5040に進むのは、ヘッダファイル９３０がなければ、手続き間最適化対象外のプログラムコードからその手続きが呼び出されるか否かの判別が出来ないからである。このためS5040に進んで、その手続きのクローニングを行うようにしている。

図２２のアルゴリズムの適用例を以下に示す。
まず、図２２のS5000で手続きAを処理の対象とすると、S5010で手続きAはMAIN関数でないのでS5020へ進み、S5020では呼び出し元手続きがないのでS5000へ戻り、手続きAについては、なにもしないで終了する。
手続きBは、S5010でMAIN関数でないのでS5020へ進み、S5020では呼び出し元手続きとして手続きAがあるのでS5030へ進み、S5030ではヘッダファイル９３０があるので、S5050へ進む。S5050ではヘッダファイル９３０に手続きBの宣言がないのでS5000へ戻る。
手続きCは、S5010でMAIN関数でないのでS5020へ進み、S5020では呼び出し元手続きとして手続きAがあるのでS5030へ進み、S5030ではヘッダファイル９３０があるので、S5050へ進む。S5050ではヘッダファイル９３０に手続きCの宣言があるのでS5040へ進む。S5040では、クローニングの処理などを行なう。
手続きDは、S5010でMAIN関数でないのでS5020へ進み、S5020では呼び出し元手続きとして手続きB,CがあるのでS5030へ進み、S5030ではヘッダファイル９３０があるので、S5050へ進む。S5050ではヘッダファイル９３０に手続きDの宣言がないのでS5000へ戻る。

この結果、図２３のようなコールグラフ７００になり、実施例２と同様な手続き間最適化ができる。つまり、手続きB,Dには手続き間最適化対象外からの呼び出しがないので、不明な呼び出し元がなく、そのため手続きのクローニングが適用されない。手続きCには手続き間最適化対象外からの呼び出しがあるのでクローニングが適用されている。このように呼び出し元を調べることにより、実施例１の場合と比べて、手続きB,Dのクローニングがなくなり、無駄なクローニングを行なわないようにすることが可能となる。

以上本実施の形態について説明したが、本実施の形態によれば、部分的なプログラムコードに対して手続き間最適化を行なうことができるようになる。これにより、コンパイルを行なう計算機の資源が少ない場合でも手続き間最適化が行なえるようになる。

また、ライブラリのプログラムコードのみに対して手続き間最適化が行なえるようになる。これにより、ライブラリを使うプログラムコードには変更を加えずに、プログラムコードの最適化をおこなうことができるようになる。さらに、オブジェクトコードのみが提供され、ソースコードが提供されない場合においては、そのオブジェクトコードを使用しても、他のソースコード内にある手続き間だけで手続き間最適化が行なえるようになる。

また実施例２乃至実施例５において説明したように、最適化を行なう手続きに対して呼び出し元の手続きの有無を指定したり、調べたりすることにより、不要な手続きの複製を行わないようにすることも可能になる。

例えば実施例２で説明したように、リンク時に手続き間最適化を行なう場合で、手続き間最適化を適用するオブジェクトコードと手続き間最適化を適用しないオブジェクトコードが混在するときは、手続き間最適化を適用しないオブジェクトコード内にある手続きの参照情報を調べることにより、不明な呼び出し関係の有無を調べる。すなわち、手続き間最適化非適用のオブジェクトコードの中から、手続き間最適化適用オブジェクトコードの中の手続きへの参照の有無を調べることで、不明な呼び出し関係の有無を調べる。これにより、上記のクローニングを適用する手続きの数を減らすことができる。

また実施例３や実施例４で説明したように、ソースプログラムコード中のコンパイラ指示文やコンパイルオプションにより不明な呼び出し関係がない手続きを指定することにより、上記のクローニングを適用する手続きの数を減らすようにすることもできる。

また実施例５で説明したように、ライブラリに対して手続き間最適化を行なう場合は、ライブラリのヘッダファイルにある手続きの宣言を調べることにより、ライブラリを使用するプログラムコードからの呼び出しの有無を調べて、不明な呼び出し関係の有無を調べる。このようにしても上記のクローニングを適用する手続きの数を減らすことができる。

以上発明を実施するための最良の形態について説明したが、上記実施の形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明はその趣旨を逸脱することなく変更、改良され得ると共に、本発明にはその等価物も含まれる。

本実施の形態に係る情報処理装置の構成を示すブロック図である。本実施の形態に係るコンパイラとリンカを示す図である。本実施の形態に係るコンパイラを示す図である。本実施の形態に係るプログラムコードの手続き間最適化を示す図である。本実施の形態に係るコールグラフを示す図である。本実施の形態に係るコールグラフを示す図である。本実施の形態に係るコールグラフを示す図である。本実施の形態に係るリンカを示す図である。本実施の形態に係る手続き間最適化の処理の流れを示すフローチャートである。本実施の形態に係るプログラムコードを示す図である。本実施の形態に係るコールグラフを示す図である。本実施の形態に係るコールグラフを示す図である。本実施の形態に係るリンカを示す図である。本実施の形態に係る手続き間最適化の処理の流れを示すフローチャートである。本実施の形態に係るオブジェクトコードを示す図である。本実施の形態に係るコールグラフを示す図である。本実施の形態に係るコンパイラオプションを示す図である。本実施の形態に係る手続き間最適化の処理の流れを示すフローチャートである。本実施の形態に係るプログラムコードを示す図である。本実施の形態に係る手続き間最適化の処理の流れを示すフローチャートである。本実施の形態に係るプログラムコードを示す図である。本実施の形態に係る手続き間最適化の処理の流れを示すフローチャートである。本実施の形態に係るコールグラフを示す図である。

符号の説明

２００情報処理装置
７００コールグラフ
８００コード変換プログラム
８０１コンパイラ
８０２リンカ
８１０オペレーティングシステム
９００ソースコード
９１０オブジェクトコード
９２０実行コード
９３０ヘッダファイル
９４０オブジェクトコードライブラリ

Claims

複数のルーチンを含んで構成されるプログラムコードを記憶する情報処理装置に、
前記プログラムコードを構成する各ルーチンのうち、他のルーチンから呼び出される各ルーチンについて、それぞれの複製を生成する手順と、
前記プログラムコードを構成する各ルーチン及び各複製に含まれる、他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換える手順と、
前記プログラムコードを構成する各複製に含まれる各命令語を、前記各複製を呼び出すルーチン又は複製によりそれぞれ実現される情報処理を合理化するようにそれぞれ書き換える手順と、
を実行させるためのプログラム。
前記情報処理装置に、前記プログラムコードを構成する各ルーチンのうち、複製を生成するルーチンを指定する情報の入力をユーザインタフェースから受ける手順と、を実行させ、
前記複製を生成する手順においては、前記情報により指定される各ルーチンについて、それぞれの複製を生成し、
前記他のルーチンの複製を呼び出す命令語に書き換える手順においては、前記他のルーチンの複製が生成されている場合には、前記他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換える
ことを特徴とする請求項１に記載のプログラム。
前記情報処理装置に、前記プログラムコードを構成する各ルーチンのうち、複製を生成しないルーチンを指定する情報の入力をユーザインタフェースから受ける手順と、を実行させ、
前記複製を生成する手順においては、前記プログラムコードを構成する各ルーチンのうち、前記情報により指定されるルーチン以外の各ルーチンについて、それぞれの複製を生成し、
前記他のルーチンの複製を呼び出す命令語に書き換える手順においては、前記他のルーチンの複製が生成されている場合には、前記他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換える
ことを特徴とする請求項１に記載のプログラム。
前記プログラムコードには、複製を生成するルーチンを指定する情報が含まれ、
前記複製を生成する手順においては、前記情報により指定される各ルーチンについて、それぞれの複製を生成し、
前記他のルーチンの複製を呼び出す命令語に書き換える手順においては、前記他のルーチンの複製が生成されている場合には、前記他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換える
ことを特徴とする請求項１に記載のプログラム。
複数のルーチンを含んで構成される第１のプログラムコード及び第２のプログラムコードを記憶する情報処理装置に、
前記第２のプログラムコードを構成する各ルーチンに含まれる各命令語のうち、前記第２のプログラムコードを構成しないルーチンを呼び出す命令語にそれぞれ含まれる、前記第２のプログラムコードを構成しない前記ルーチンを示す情報を記憶する手順と、
前記第１のプログラムコードを構成する各ルーチンのうち、前記情報により示される各ルーチンについて、それぞれの複製を生成する手順と、
前記第１のプログラムコードを構成する各ルーチン及び各複製に含まれる、他のルーチンを呼び出す命令語のうち、前記他のルーチンの複製が生成されている場合には、前記他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換える手順と、
前記第１のプログラムコードを構成する各複製に含まれる各命令語を、前記各複製を呼び出すルーチン又は複製によりそれぞれ実現される情報処理を合理化するようにそれぞれ書き換える手順と、
を実行させるためのプログラム。
複数のルーチンを含んで構成される第１のプログラムコード及び第２のプログラムコードと、前記第１のプログラムコードを構成する各ルーチンのうち、前記第２のプログラムコードを構成するルーチンから呼び出されるルーチンを示す情報を含んで構成される第３のプログラムコードと、を記憶する情報処理装置に、
前記第１のプログラムコードを構成する各ルーチンのうち、前記第３のプログラムコードに含まれる前記情報により示される各ルーチンについて、それぞれの複製を生成する手順と、
前記第１のプログラムコードを構成する各ルーチン及び各複製に含まれる、他のルーチンを呼び出す命令語のうち、前記他のルーチンの複製が生成されている場合には、前記他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換える手順と、
前記第１のプログラムコードを構成する各複製に含まれる各命令語を、前記各複製を呼び出すルーチン又は複製によりそれぞれ実現される情報処理を合理化するようにそれぞれ書き換える手順と、
を実行させるためのプログラム。
複数のルーチンを含んで構成されるプログラムコードを構成する各ルーチンのうち、他のルーチンから呼び出される各ルーチンについて、それぞれの複製を生成し、
前記プログラムコードを構成する各ルーチン及び各複製に含まれる、他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換え、
前記プログラムコードを構成する各複製に含まれる各命令語を、前記各複製を呼び出すルーチン又は複製によりそれぞれ実現される情報処理を合理化するようにそれぞれ書き換える
ことを特徴とするプログラムコードの合理化方法。
複数のルーチンを含んで構成されるプログラムコードを構成する各ルーチンのうち、他のルーチンから呼び出される各ルーチンについて、それぞれの複製を生成し、
前記プログラムコードを構成する各ルーチン及び各複製に含まれる、他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換え、
前記プログラムコードを構成する各複製に含まれる各命令語を、前記各複製を呼び出すルーチン又は複製によりそれぞれ実現される情報処理を合理化するようにそれぞれ書き換える
ことによりプログラムコードを生成する方法。
複数のルーチンを含んで構成されるプログラムコードを構成する各ルーチンのうち、他のルーチンから呼び出される各ルーチンについて、それぞれの複製を生成し、
前記プログラムコードを構成する各ルーチン及び各複製に含まれる、他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換え、
前記プログラムコードを構成する各複製に含まれる各命令語を、前記各複製を呼び出すルーチン又は複製によりそれぞれ実現される情報処理を合理化するようにそれぞれ書き換える
ことにより生成されるプログラムコード。
複数のルーチンを含んで構成されるプログラムコードを記憶するプログラムコード記憶部と、
前記プログラムコードを構成する各ルーチンのうち、他のルーチンから呼び出される各ルーチンについて、それぞれの複製を生成する複製ルーチン生成部と、
前記プログラムコードを構成する各ルーチン及び各複製に含まれる、他のルーチンを呼び出す命令語を、それぞれ前記他のルーチンの複製を呼び出す命令語に書き換える呼び出し命令変更部と、
前記プログラムコードを構成する各複製に含まれる各命令語を、前記各複製を呼び出すルーチン又は複製によりそれぞれ実現される情報処理を合理化するようにそれぞれ書き換える最適化実行部と、
を備えることを特徴とする情報処理装置。