JP2015001807A - 並列化コンパイル方法、並列化コンパイラ、並列化コンパイル装置、及び、車載装置 - Google Patents

Abstract

【課題】開発期間や開発費を抑えつつ、信頼性が高く、高速な処理が可能な車載装置用の組込みシステム向けの並列化プログラムを作成する。【解決手段】自動並列化コンパイラは、シングルプロセッサシステムにより実行される組込みシステム用の逐次プログラムを複数のマクロタスクに分割した後（Ｓ２１０）、制御依存性を有するマクロタスクを一つのマクロタスクに融合する（Ｓ２１５）。その後、データ依存性に基づき並列実行可能なマクロタスクを抽出すると共に（Ｓ２２０）と、スタティックスケジューリングを行い（Ｓ２２５）、並列化プログラムを生成する（Ｓ２２５，Ｓ２３０）。【選択図】図１８

Description

本発明は、シングルプロセッサシステムにより逐次実行される車載装置向けの組込みシステム用の逐次プログラムから、車載装置に搭載されたマルチプロセッサシステム用の並列化プログラムを生成する並列化コンパイル方法，並列化コンパイラ，並列化コンパイル装置と、マルチプロセッサシステムが搭載された車載装置に関する。

より安全，快適，低価格且つ省エネを実現する世代自動車の開発のため、エンジン制御のようなリアルタイム制御系、人認識・他車認識や運転に必要な情報の提示や音楽・映像等の出力を行う情報系の高度化及び統合化が重要となっている。

制御系，情報系の高度化，統合化のためには、それらを実現するためのプロセッサの高能力化が重要となる。例えば、安全，快適で燃費の良い自動車開発のために重要なエンジン制御系を高度化するためには、制御アルゴリズムの高度化や新たな制御機能の実現等、計算負荷の増大を避けられない。このような問題を解決する為には、リアルタイム制御を実現しているプロセッサの高速化が必須となる。

しかし、従来のようにプロセッサの動作周波数を向上させることは、消費電力が周波数の三乗に比例して増大するため、困難となっている。このため、１チップ上に低動作周波数のプロセッサコアを複数集積し、電力削減のために低周波数化・低電圧化したプロセッサコアを並列動作させることで、処理の高速化と低電力化を同時に実現可能なマルチコアプロセッサへの移行が急ピッチで行われている。

ここで、マルチコアプロセッサにて、シングルコアプロセッサよりも高速な処理を行うためには、シングルコアプロセッサ用の逐次プログラムの処理を分割し、プロセッサコア間の通信が最小になる形で各プロセッサコアに各処理を割り当てる必要がある。従来、このような逐次プログラムの並列化の作業は人手で行う必要があったが、このような作業は大変困難で長期間を要し、開発費の増加や並列化されたプログラムの信頼性等、多くの課題が生じている。

ここで、非特許文献１には、マルチコアプロセッサが搭載された車載装置において、各プロセッサコアに機能を分散させることで、スループットを向上させることが記載されている。

K Seo，J Yoon，J Kim，T Chung，K Yi，N Chang、「Coordinated implementation and processing of a unified chassis control algorithm with multi-central processing unit」、JAUTO1346 IMechE、２００９年、Vol.224 Part D

しかしながら、各プロセッサコアの処理能力を最大限利用するためには、並列実行可能な処理を抽出して異なるプロセッサコアに割り当てる必要がある。このため、単に各プロセッサコアに機能を分散させるのみでは、スループットを向上させることはできてもレイテンシを削減することができず、高速な処理を行うことはできない。

本願発明は上記課題に鑑みてなされたものであり、開発期間や開発費を抑えつつ、信頼性が高く、高速な処理が可能な車載装置用の組込みシステム向けの並列化プログラムを作成することができる並列化コンパイル方法等を提供する。

上記課題に鑑みてなされた請求項１に係る並列化コンパイル方法は、シングルプロセッサシステムにより実行される車載装置向けの組込みシステム用の逐次プログラムを、予め定められた方法に従い複数のマクロタスクに分割する分割手順と、マクロタスク間の制御依存性に基づき、異なるマクロタスクに分岐する処理を有するマクロタスクを始端タスクとして特定すると共に、該始端タスクを始点として順次実行される複数の一連の処理の全てにおいて共通して実行されるマクロタスクのうちのいずれか一つを終端タスクとして特定する特定手順と、を有する。

また、当該コンパイル方法は、特定手順により特定された始端タスクと、該始端タスクを始点とする処理における終端タスクと、該始端タスクの実行後であって、該終端タスクの実行前に実行される全てのマクロタスクとを、新たなマクロタスクとして融合させる融合手順と、融合手順による融合がなされた後のマクロタスク間のデータ依存性に基づき、車載装置に搭載されたマルチプロセッサシステムを構成する複数のプロセッサユニットにより並列実行可能なマクロタスクを抽出する抽出手順と、を有する。

また、当該コンパイル方法は、並列実行可能なマクロタスクが異なるプロセッサユニットにより並列的に実行されるよう、それぞれのマクロタスクをいずれかの前記プロセッサユニットに割り当てるスタティックスケジューリングを行うスケジューリング手順と、スタティックスケジューリングの結果に基づき、マルチプロセッサシステムにより実行される並列化プログラムを生成する生成手順と、を有する。

逐次プログラムを並列化する方法としては、粗粒度並列化，中粒度並列化，近細粒度並列化を組み合わせて行うマルチグレイン並列処理が知られている。
しかし、車載装置用の組込みシステム向けの逐次プログラムは、ループ構造が存在しないか、或いは非常に少なく、主に条件分岐と代入文から構造されているため、中粒度並列化（ループ内イタレーションレベルの並列化）を適用することはできない。さらに、処理が非常に細かいため、マルチプロセッサシステムにより並列実行される際のオーバーヘッドを抑える必要がある。

そこで、請求項１に記載の並列化コンパイル方法では、シングルプロセッサシステムにより実行される車載装置向けの組込みシステム用の逐次プログラムをマクロタスクに分割すると共に、各マクロタスクの並列性を抽出し、並列実行可能なマクロタスクを異なるプロセッサユニットに割り当てる粗粒度並列化が行われる。

また、車載装置用の組込みシステム向けの逐次プログラムから得られた各マクロタスクは、サイクルが短いため、ダイナミックスケジューリングを適用するとオーバーヘッドが大きくなり、高速化が困難となる。そこで、スタティックスケジューリングを適用することが考えられるが、マクロタスク間に制御依存性がある場合には、これを適用することはできない。

これに対し、請求項１に記載の並列化コンパイル方法では、融合手順により制御依存性のある複数のマクロタスクが一つのタスクに融合された後にスタティックスケジューリングが行われ、並列実行可能なマクロタスクが異なるプロセッサユニットに割り当てられる。

これにより、車載装置用の組込みシステム向けの逐次プログラムから、高速な処理が可能な並列化プログラムを自動生成することができる。したがって、従来のように人手により逐次プログラムの並列化を行う場合に比べ、開発期間や開発費を抑えつつ、高い信頼性を有する車載装置用の組込みシステム向けの並列化プログラムを作成することができる。

なお、本発明は、上述した並列化コンパイル方法のほか、種々の形態で実現することができる。このような形態の具体例としては、当該並列化コンパイル方法をコンピュータに実現させるためのプログラムである並列化コンパイラや、当該並列化コンパイル方法を実現するための並列化コンパイル装置等が考えられる。また、当該並列化コンパイル方法により生成されたプログラムにより動作するマルチプロセッサシステムを備える車載装置等が考えられる。

自動並列化コンパイラの構成を示すブロック図である。 階層的に定義されるマクロタスクについての説明図である。 マクロフローグラフの一例である。 マクロタスクグラフの一例である。 プロファイル自動フィードバック機能を用いた場合のコンパイル手順についての説明図である。 プロファイル自動フィードバック機能を用いた場合のコンパイル手順についてのフローチャートである。 マクロタスクグラフの一例である。 依存があるループ間におけるキャッシュのグローバル最適化のための分割がなされたマクロタスクグラフの一例である。 分割ループのプロセッサへの割り当ての様子を示す説明図である。 最速実行モードでの、各ＰＧに割り当てられたマクロタスクの実行状態についての説明図である。 リアルタイムモードでの、各ＰＧに割り当てられたマクロタスクの実行状態についての説明図である。 自動並列化ＡＰＩの一例である。 本実施形態のマルチコアアーキテクチャのブロック図である。 自動並列化ＡＰＩ標準解釈系と開発環境についての説明図である。 自動並列化ＡＰＩの指示文の一例である。 自動並列化ＡＰＩ標準解釈系により生成されたランタイムライブラリ関数の一例である。 自動並列化コンパイラがインストールされたＰＣの構成を示すブロック図である。 自動並列化処理のフローチャートである。 自動車制御プログラムの一例である。 自動車制御モデルと、これに基づき自動生成されたＣ言語の自動車制御プログラムの一例である。 インライン展開後のマクロフローグラフの一例である。 インライン展開前のマクロタスクグラフの一例である。 インライン展開後のマクロタスクグラフの一例である。 ローカル変数が繰り返し使用された自動車制御プログラムの一例である。 タスク融合前のマクロフローグラフの一例である。 タスク融合前のマクロタスクグラフの一例である。 タスク融合後のマクロフローグラフの一例である。 タスク融合後のマクロタスクグラフの一例である。 エンジン制御ＥＣＵの構成を示すブロック図である。

以下、本発明の実施形態について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態を採りうる。

１．自動並列化コンパイラについて
本実施形態の自動並列化コンパイラ１は、組込みシステム向けのシングルプロセッサシステム用のソースプログラム（逐次プログラム）から、組込みシステム向けのマルチプロセッサシステム用の並列化プログラムを生成する機能を有している。

１−１．自動並列化コンパイラ１の設計概念
本実施形態の自動並列化コンパイラ１は、以下の機能を有している。
（１）マルチグレイン並列処理
（２）コンパイル時のスタティックスケジューリングコードの挿入
（３）実行時のダイナミックスケジューリングコードの生成
（４）階層型マクロデータフローの実現
（５）マクロタスクの分割／融合，Loop distribution／interchange等の並列性抽出
（６）データローカライズによるデータ転送効率の向上
（７）コンパイラによる電力削減
１−２．自動並列化コンパイラの内部処理
自動並列化コンパイラ１は、Front End（ＦＥ３），Middle Path（ＭＰ５），Back End（ＢＥ７）の３つのステージを有している（図１参照）。各ステージは実行形態として独立しており、ＦＥ３，ＭＰ５から生成される中間言語４，６（Intermediate language）によりコード授受が行われる。

なお、ＦＥ３は、逐次プログラムのソースコード２を字句解析・構文解析を行い、ＭＰ５においてparse可能な中間言語４を生成する部位である。ＦＥ３の生成する中間言語４は、基本的に４つのオペランドを持つ解析木（parse tree）で表現されており、全体として１つのブロックを形成していて構造化は行われていない。

また、ＭＰ５は、制御依存性解析・データ依存性解析・最適化等を行う部位であり、そのデータを用いて粗粒度（Macro Data Flow）・中粒度（Micro tasking/Doall loop parallelize）・近細粒度（Near fine grain）並列化のマルチグレイン並列処理を行う。

また、ＢＥ７は、ＭＰ５が生成した並列化中間言語６を読み込んで実際のマシンコードを生成する部位である。当該部位は、ターゲットとなっているマルチコアアーキテクチャのアセンブラコード８ａを生成するＢＥの他、OpenMP用の並列化FortranコードやＣコードを生成するＢＥを有している。さらには、当該部位は、後述する並列化ＡＰＩ９によりメモリ配置，データ転送を含めて並列化したコード８ｂ，８ｃを生成するＢＥ等、多様なアーキテクチャに対応したコードを出力するＢＥを有している。

１−３．自動並列化コンパイラの並列性解析
自動並列化コンパイラ１は、逐次プログラムを、基本ブロック（ＢＢ），繰り返しブロック（ＲＢ），サブルーチンブロック（ＳＢ）の３種類の粗粒度タスク（マクロタスク（ＭＴ））に分割するマクロデータフロー処理を行う。

しかし、マクロデータフロー処理では、プログラムの形状によってはプロセッサの利用効率が上がらず、十分な粗粒度並列性が抽出できないという問題点がある。
そこで、自動並列化コンパイラ１では、従来の単階層マクロデータフロー処理手法を拡張し、ＭＴ内部に対してマクロデータフロー処理を階層的に利用する階層型マクロデータフロー処理を採用している。階層的マクロデータフロー処理では、図２に示すようなＭＴの階層的な定義を行う。その上で、生成された各階層のマクロタスクに対して、マクロタスク間の並列性の解析を行う。

＜マクロフローグラフ（ＭＦＧ）の生成＞
自動並列化コンパイラ１は、まず、生成された各階層のマクロタスクに対して、マクロタスク間の制御依存性とデータ依存性を解析する。この解析結果は、マクロフローグラフ（ＭＦＧ）として表される（図３参照）。

図３においては、ノードはマクロタスクを、実線エッジはデータ依存を、点線エッジは制御依存を、ノード内の小円は条件分岐を表す。なお、該ＭＦＧではエッジの矢印は省略されているが、エッジの方向は下向を仮定している。

＜マクロタスクグラフ（ＭＴＧ）の生成＞
ＭＦＧは、マクロタスク間の制御依存性とデータ依存性を表すが、並列性は表していない。並列性を抽出するためには、各マクロタスクに対し、制御依存性とデータ依存性の両方を考慮した最早実行可能条件解析を行う必要がある。最早実行可能条件とは、そのＭＴが最も早い時点で実行可能になる条件であり、次のような実行条件から求められる。

（１）ＭＴｉがＭＴｊにデータ依存するならば、ＭＴｊの実行が終了するまでＭＴｉは実行できない。
（２）ＭＴｊの条件分岐先が確定すれば、ＭＴｊの実行が終了しなくても、ＭＴｊに制御依存するＭＴｉは実行できる。

したがって、最早実行可能条件の一般形は次のようになる。
（ＭＴｉが制御依存するＭＴｊがＭＴｉに分岐する）
ＡＮＤ
（（ＭＴｉがデータ依存するＭＴｋ（０≦ｋ≦｜Ｎ｜））が終了）ＯＲ（ＭＴｋが実行されないことが決定する））
例えば、図３のＭＦＧのＭＴ６の最早実行可能条件は、次のようになる。

（（ＭＴ１がＭＴ３に分岐）ＯＲ（ＭＴ２がＭＴ４に分岐））
ＡＮＤ
（（ＭＴ３が終了する）ＯＲ（ＭＴ１がＭＴ２に分岐））
ＭＦＧにおける制御依存性を考えると、ＭＴ３が終了するということは、ＭＴ１はＭＴ３に分岐したということを含み、また、ＭＴ２がＭＴ４に分岐するということは、ＭＴ１はＭＴ２に分岐しているので、この条件は、簡略化されて次のようになる。

（（ＭＴ３が終了する）ＯＲ（ＭＴ２がＭＴ４に分岐））
マクロタスクの最早実行可能条件は、図４に示すようなマクロタスクグラフ（ＭＴＧ）で表される。

ＭＦＧと同様に、ＭＴＧにおけるノードはマクロタスクを、ノード内の小円はマクロタスク内の条件分岐を、実線のエッジはデータ依存を、点線のエッジは拡張された制御依存を表す。なお、拡張された制御依存とは、通常の制御依存だけでなく、データ依存と制御依存を複合的に満足させるため、先行ノードが実行されないことが確定するという条件分岐を含んでいる。

また、エッジを束ねるアークには２つの意味があり、実線アークは、当該アークによって束ねられたエッジがＡＮＤ関係にあることを、点線アークは、当該アークによって束ねられたエッジがＯＲ関係にあることを示している。

また、ＭＴＧにおいてはエッジの矢印は省略されているが、下向きが想定されている。また、矢印を持つエッジは、オリジナルの制御依存性を表す。
１−４．マルチグレイン並列処理
自動並列化コンパイラ１では、従来のループ並列化に加え、ループ間，サブルーチン間における粗粒度タスク間の並列性を利用する粗粒度タスク並列処理や、ステートメント間の並列性を利用する近細粒度並列処理を効果的に組み合わせたマルチグレイン並列処理（参考文献１（本多弘樹, 岩田雅彦, 笠原博徳、「Fortranプログラム粗粒度タスク間の並列性検出手法」、電子情報通信学会論文誌、１９９０年）参照）を実現している。

＜粗粒度タスク並列処理＞
自動並列化コンパイラ１は、ＢＢ，ＲＢ，ＳＢ等のＭＴ間の制御依存性とデータ依存性を表現したマクロフローグラフ（ＭＦＧ）を生成し、さらに、ＭＦＧから最早実行可能条件解析により引きだしたＭＴ間の並列性を、マクロタスクグラフ（ＭＴＧ）として表現する（参考文献１，参考文献２（笠原，合田，吉田，岡本，本多、「Fortranマクロデータフロー処理のマクロタスク生成手法」、信学論、１９９２年、Vol.J75-D-I、No.8、pp.511-525）参照）。

その後、自動並列化コンパイラ１は、ＭＴＧ上のＭＴを、１つ以上のプロセッサエレメント（ＰＥ）をグルーピングしたプロセッサグループ（ＰＧ）に割り当てる。
＜中粒度並列処理＞
ＰＧに割り当てられたＭＴが、DOALLループ、或いはイタレーションレベルで並列処理が可能なものであれば、そのＭＴには、プロセッサクラスタ内のプロセッサによって中粒度並列処理がなされる。この中粒度並列処理は、ＤＯループイタレーション間の並列性を利用する並列処理のことであり、マルチプロセッサにおける並列処理では最も一般的なものである。

＜近細粒度並列処理＞
ステートメントレベルの近細粒度タスクに対する並列処理を、近細粒度並列処理という。これによって、依存の無いステートメントも並列実行が可能になり、実行時間が短縮される。これが行われるのは、分岐のない逐次実行される基本ブロックと、シーケンシャルループ内のボディ部である。近細粒度並列処理では、ステートメントを、コンパイラによるスタティックスケジューリングによって各ＰＥに割り当て、自動並列化コンパイラ１は、各ＰＥ用のマクロタスクコードとして、必要な同期，データ転送コードと共に割り当てられたステートメントのみを生成する。近細粒度並列処理は、ステートメントという小さな粒度のタスクを用いた並列処理であり、タスクの実行時間は短いものが多い。したがって、効率的に行うためには、ＰＥ間の高速なデータ転送がサポートされていることが必要である。

１−５．マクロタスクスケジューリング
粗粒度タスク並列処理では、各階層で生成されたマクロタスクは、ＰＧに割り当てられて実行される。どのＰＧにマクロタスクを割り当てるかを決定するスケジューリング手法として、下記のダイナミックスケジューリングとスタティックスケジューリングがあり、これらは、マクロタスクグラフの形状や実行時非決定性等を元に選択される。

＜ダイナミックスケジューリング＞
条件分岐等の実行時不確定性が存在する場合には、ダイナミックスケジューリングによって実行時にマクロタスクをＰＧに割り当てる。ダイナミックスケジューリングルーチンは、マクロタスクの終了や分岐方向の決定に応じてマクロタスク実行管理テーブルを操作し、各マクロタスクの最早実行可能条件を検査する。

マクロタスクが実行可能であれば、レディキューにマクロタスクが投入される。レディキュー内のマクロタスクは、その優先順位に従ってソートされ、レディキューの先頭のマクロタスクが、アイドル状態のプロセッサクラスタに割り当てられる。

また、ダイナミックスケジューリングコード生成時には、一つの専用のプロセッサがスケジューリングを行う集中スケジューリング方式と、スケジューリング機能を各プロセッサに分散した分散スケジューリング方式を、使用するプロセッサ台数，システムの同期オーバーヘッドに応じて使い分けることができる。

＜スタティックスケジューリング＞
一方、スタティックスケジューリングは、マクロタスクグラフがデータ依存エッジのみを持つ場合に使用され、自動並列化コンパイラ１が、コンパイル時にＰＧへのマクロタスクの割り当てを決める方式である。

スタティックスケジューリングは、実行時スケジューリングオーバーへッドを無くし、データ転送と同期のオーバーへッドを最小化することが可能であるため、粒度の細かいタスクのスケジューリングに対しても効果的に利用できる。

また、スタティックスケジューリングの際、タスクのコストは自動並列化コンパイラ１でのタスクコスト推定値を適用するが、自動並列化コンパイラ１のプロファイル自動フィードバック機能を用いることで、実コストでタスクスケジューリングを行うことも可能である。

プロファイル自動フィードバック機能を用いた場合のコンパイルフローを、図５，６に示す。プロファイル自動フィードバック機能を用いる場合、第１フェーズとして、逐次プログラムをＭＴに分解し、ＭＴ毎にプロファイラ関数を挿入して逐次プログラムを生成する（図５参照）。このプロファイラ関数では、タスク実行コスト（clock cycle）とタスク実行回数を計測する。このプロファイラ関数が挿入された逐次プログラムを一度ターゲットとなるマシン上で実行することで、ターゲットとなるマシン上でのタスク実行コストとタスク実行回数の情報を持つファイルを出力する。

そして、第２フェーズにて、この出力ファイルと逐次プログラムを入力として、実コストに基づきスケジューリングした並列化プログラムが生成される（図６参照）。
１−６．データローカライゼーション
自動並列化コンパイラ１は、プログラム全域に渡るキャッシュ最適化を行うことが可能である。自動並列化コンパイラ１は、ループ間などの並列性を解析した後、図７の網掛けされた６つのＭＴ２，３，７，８，１１，１４が、実線で示すデータ依存エッジで結ばれたマクロタスクグラフのようにループ間にデータ依存があることが分かると、依存があるループ間でのキャッシュのグローバル最適化を試みる（参考文献３（特許第４１７７６８１号公報）参照）。

具体的には、各ループでアクセスされる配列を調査し、図８の４つのループ２０，２１，２２，２３に分割し、同一の分割ループは同一の配列部分にアクセスするように調整することにより、同一の分割ループを同一プロセッサに割り当てる（図９参照）。これにより、同一の分割ループでは、全ての配列データがキャッシュ上で再利用されるようになる。

また、このローカライズ技術は、
（１）任意のサイズのローカルメモリ或いは分散共有メモリが与えられた時に、ＤＭＡ（ＤＴＵ）（参考文献４（特許第４４７６２６７号公報）参照）を用いアクセスされる前に、前記プロセッサに近接したローカル或いは分散共有メモリに事前ロードし、プログラム全域で再利用する。

（２）送付先のメモリが一杯の場合には、送付先プロセッサのＤＴＵが、メモリからの掃き出し優先順位に従ってデータを共有メモリ等へ掃き出したことを同期フラグで知らされたら、自動的に空いたメモリにデータを転送する。

（３）将来再利用されるデータであるが、暫くの間使用されず、メモリの領域を開ける必要がある場合には、ＣＰＵによるタスク実行の裏側でＤＴＵが当該データを集中共有メモリに待避し、使用時までに再ロードする。

といったローカルメモリ管理，データ転送技術へと進化している（参考文献５（英国特許第２４７８８７４号明細書）。
１−７．自動並列化コンパイラによる電力削減
自動並列化コンパイラ１では、タスクのプロセッサへのスケジュール結果を解析し、自動的に各プロセッサの周波数電圧制御、パワーゲーティング制御により電力を削減することが可能である。

図１０に示す最速実行モードの際には、タスクグラフのクリティカルパス上のタスク集合はフルスピード（１００％の周波数）で実行される必要があり、ＰＧ０に割り当てられたＭＴ１と、ＰＧ１に割り当てられたＭＴ３が最大周波数で実行される。

しかし、ＭＴ３は、ＭＴ１の計算結果を必要とするので、ＭＴ２の実行後、ＰＧ１は同期のためのビジーウエイト状態となり、ＰＧ０がＭＴ１の出力データをＰＧ１上の分散共有メモリにストアし、ＭＴ１の終了を通知する同期フラグを分散共有メモリ上にセットするのを待つ。

この際、ビジーウエイトは電力を消費してしまうので、自動並列化コンパイラ１は、ＭＴ２を低周波数・低電力で実行するか、もしくは、電源遮断するのに十分な待ち時間があれば、ＰＧ１の電源を一時遮断する。

また、図１１に示すリアルタイム実行モードでは、処理終了後からデッドラインまでの待ち時間の電力消費を避けるため、ＭＴ１の周波数を１／４に、ＭＴ２の周波数を１／２に下げ、低電力で実行させるか、クロックゲーティング或いはパワーゲーティングにより各ＰＧを停止させる。

この時、自動並列化コンパイラ１は、電源状態遷移オーバーヘッドも考慮して、ヒューリスティック的に適切な電力モードを自動選択する（参考文献６（特許第４０８２７０６号公報）参照）。

１−８．並列化プログラムの生成
自動並列化コンパイラ１における並列化プログラムの生成は、自動並列化ＡＰＩ（参考文献７（早稲田大学、「Optimally Scheduled Advanced Multiprocessor Application Program Interface」、２００８年）参照）を用い、並列化Ｃ或いは並列化Fortranのような、source-to-sourceで並列化を行うことが可能である。

この場合には、自動並列化コンパイラ１は、様々なプラットフォームにおいて並列化プログラムを実行可能とするため、後述する自動並列化ＡＰＩ標準解釈系を用いて、各プロセッサ用のＣ或いはFortranのディレクティブ部分をランタイムライブラリコールに変換する。その後、自動並列化コンパイラ１は、各プロセッサ用のコードを逐次コンパイラでコンパイルしてバイナリを生成し、このバイナリをリンクすると、対象となるマルチプロセッサ上で並列化プログラムを実行可能となる。

１−９．自動並列化ＡＰＩ
自動並列化ＡＰＩは、後述する情報家電用のマルチコアアーキテクチャを意識したものであり、共有メモリ型マルチコアプロセッサで要求される、データのメモリ配置，ＤＭＡを用いたデータ転送，電力制御，グループバリア同期，リアルタイム制御を行うことができる。

自動並列化ＡＰＩの使用例として、自動並列化コンパイラ１とターゲットとなるマルチコア用コンパイラとの間の中間表現としての利用があげられる。
例えば、自動並列化コンパイラ１を用いることにより、Fortran77或いはポインタ利用等に制限をつけた逐次Ｃプログラムを、自動的に自動並列化ＡＰＩを加えた並列化Fortran 或いはＣプログラムに翻訳できる。この並列化プログラムをサーバ上で動作させるときには、OpenMPコンパイラを通すことにより実行バイナリを生成することができる。

また，組込みシステム用のマルチコアプロセッサで使用する場合には、専用ＡＰＩ解釈系によりランタイムライブラリを含むコードを生成し、逐次コンパイラを通すことによっても、実行バイナリを生成することができる。

図１２における自動並列化ＡＰＩの例では、“threadprivate”，“distributedshared”，“onchipshared”は、メモリ配置ＡＰＩであり、変数をどのメモリに配置するかを指定している。

また、“pararell subsections”の部分が自動並列化ＡＰＩであり、“subsection”を２つ配置することで、２スレッドを生成して処理を実行可能となっている。
また、“dma transfer”はデータ転送ＡＰＩで、“dma contiguous parameter”はＤＴＵによる連続転送を表すＡＰＩである。具体的には、該連続転送ＡＰＩは、第１引数が転送元アドレス，第２引数が転送先アドレス，第３引数が転送サイズ，第４引数が転送終了時に値が設定されるフラグ変数，第５引数がフラグに設定する値となっている。

１−１０．マルチコアアーキテクチャと自動並列化ＡＰＩ標準解釈系
自動並列化ＡＰＩ標準解釈系とは、自動並列化コンパイラ１で生成した並列化プログラムのポータビリティの実現を図るためのものである。自動並列化コンパイラ１は、生成した並列化プログラムを多様なアーキテクチャで動作させるため、自動並列化ＡＰＩ標準解釈系により生成コードをランタイムライブラリに変換し、様々なプラットフォームに合わせた並列化プログラムを生成することができる。

自動並列化コンパイラ１と自動並列化ＡＰＩにより、後述するマルチコアアーキテクチャにおいて、逐次プログラムの並列化や電力制御を自動的に行うことができるようになった。しかし、自動並列化ＡＰＩのメモリ配置ＡＰＩやデータ転送ＡＰＩを利用するには、ターゲットとなるプラットフォーム用にＡＰＩ解釈系を用意する必要があり、開発期間の短縮，開発の容易化が求められる状況において、プラットフォーム毎にＡＰＩ解釈系を開発するのは大きな負担となっている。

そこで、指示文やソースプログラムを解釈して変換する部分等のように、プラットフォームへの依存度が低い部分を自動並列化ＡＰＩ標準解釈系として提供する。これにより、多くの組込み用のマルチコアプロセッサが備えるランタイムライブラリや、比較的容易に作成可能なランタイムライブラリをプラットフォーム毎に用意すれば、並列化プログラムを生成可能となる。その結果、様々なマルチコアプロセッサにおいて、非常に低コストで、自動並列化コンパイラ１により並列化や電力制御を行うことが可能となる。

以下では、情報家電向けのマルチコアアーキテクチャの一例と、自動並列化ＡＰＩ標準解釈系の構造と変換例について述べる。
１−１１．マルチコアアーキテクチャについて
マルチコアプロセッサにおけるメモリアーキテクチャであるローカルメモリアーキテクチャは、キャッシュアーキテクチャとは異なり、ソフトウェア上で明示的なローカルメモリ管理を行うことで性能を引き出すことが可能である。

本実施形態のマルチコアアーキテクチャ５０では、１つのチップ上に複数のプロセッサエレメント（ＰＥ５１，５２，５３）を持つ（図１３参照）。各ＰＥには、中央演算処理装置（ＣＰＵ５１ａ），ローカルプログラムメモリ（ＬＰＭ５１ｂ），ローカルデータメモリ（ＬＤＭ５１ｃ），分散共有メモリ（ＤＳＭ５１ｄ），ＣＰＵと非同期に動作しデータ転送を行うことができるデータ転送ユニット（ＤＴＵ５１ｄ）が設けられている。チップ上の全てのＰＥは、バスやクロスバーといったInterconnection Network５４によって、オンチップ集中共有メモリ（OnChipCSM５５）や、オフチップ集中共有メモリに接続されている。

１−１２．自動並列化ＡＰＩ標準解釈系の構造
本実施形態の自動並列化ＡＰＩ標準解釈系７０は、自動並列化ＡＰＩを含むＣプログラム７１（或いはFortranプログラム）を入力とし、設定ファイル７２の設定に従いランタイムライブラリ関数を含むＣプログラム７３（或いはFortranプログラム）を出力する（図１４参照）。

設定ファイル７２は、アーキテクチャ毎の設定を記述することができ、分散共有メモリ（ＤＳＭ）のアドレスや、ネイティブコンパイラに対する指示を伝搬可能とする“comment指示文”や、データ転送ＡＰＩ及び電力制御ＡＰＩの変換や、プロセッサコア間で任意のグループによるバリア同期を実現する“groupbarrier 指示文”や、モジュール名とモジュール番号の対応付け等に関する設定ができる。

また、出力されたランタイムライブラリ関数を含むＣプログラム７３を、各開発環境８０のコンパイラ８１でコンパイルし、ランタイムライブラリ８２，８３とリンクすることで、実行ファイル８４を生成することができる。

１−１３．ランタイムライブラリコールへの変換
自動並列化ＡＰＩの指示文は、Ｃプログラムでは“pragma”により記述されるが、これらの自動並列化ＡＰＩの指示文は、自動並列化ＡＰＩ標準解釈系によりランタイムライブラリ関数へ変換される。

＜並列実行指示文＞
図１５の自動並列化ＡＰＩの指示文では、“parallel subsections指示文”により４つのスレッドを生成している。図１６のソースプログラムのように、自動並列化ＡＰＩ標準解釈系では、スレッドとして実行するプログラム部分を、“thread_function_000〜003”という関数として切り出す。これらの切り出された関数のうち、“thread_function_001〜003”は、“oscar_thread_create関数”によりスレッドとして実行し、“thread_function_000”は、そのまま通常の関数として実行する。最後に、“oscar_thread_join”関数により、スレッド終了の待ち合わせを行う。

また、“pthreadライブラリ”が利用可能なプラットフォームでは、“oscar_thread_create”及び“oscar_thread_join”を、pthread create 及びpthread join を用いてそれぞれ実装すれば良い。

１−１４．メモリ配置属性の指定
“thread private 指示文”等のメモリ配置指定は、ランタイムライブラリでは実現できない。そのため、これらのメモリ配置指定は、ネイティブコンパイラ用のメモリ属性指定の記述に変換する必要がある。

具体例を挙げると、“#pragma oscar onchipshared(var1)”という記述は、変数“var1”をオンチップ集中共有メモリに配置するように指定するものである（“onchipshared 指示文”）。

ネイティブコンパイラとしてｇｃｃを用いる場合、上記記述は、“int__attribute((subsection("OSCAR_SHARED")))var1;”という記述に変換される。該記述では、“attribute記述”により、変数“var1”を“OSCAR SHAREDセクション”に配置している。対象プラットフォーム用リンカの設定ファイルにより“OSCAR SHARED”セクションをオンチップ集中共有メモリに配置することで、リンカが変数“var1”がオンチップ集中共有メモリ上に配置される。

２．自動車制御プログラムの並列化手順と手法
次に、モデルベース設計で自動生成された自動車制御プログラムの特徴について述べ、自動並列化コンパイラ１による並列化手法について説明する。

具体的には、自動並列化コンパイラ１は、条件分岐と代入文により構成され、処理が細かい自動車制御プログラムに対して、インライン展開やリネーミングを行い、並列性を抽出する。また、リアルタイム性を順守するために条件分岐隠蔽のためのタスク融合を行い、オーバーヘッドが低くなるようにスタティックスケジューリングを行う。さらに、実コストでスタティックスケジューリングを行うために、プロファイル自動フィードバック機能を適用しても良い。

２−１．自動並列化コンパイラの動作環境等について
自動並列化コンパイラ１は、例えば、ＤＶＤ，ＣＤ−ＲＯＭ，ＵＳＢメモリ，メモリカード（登録商標）等の光ディスク，磁気ディスク，半導体製メモリ等として構成された記憶媒体１８０に記憶された状態で、ユーザに提供される（図１７参照）。無論、ネットワークを経由してユーザに提供されても良い。

そして、自動並列化コンパイラ１がインストールされたパーソナルコンピュータ（ＰＣ）１００は、自動並列化コンパイル装置として動作する。ＰＣ１００は、ディスプレイ１１０，ＨＤＤ１２０，ＣＰＵ１３０，ＲＯＭ１４０，ＲＡＭ１５０，入力装置１６０，読取部１７０等を備える。

ディスプレイ１１０は、ＣＰＵ１３０から受けた映像信号を、ユーザに対して映像として表示する。
また、入力装置１６０は、キーボード、マウス等から構成され、ユーザが操作することにより、その操作に応じた信号をＣＰＵ１３０に出力する。

また、読取部１７０は、自動並列化コンパイラ１等が記憶された記憶媒体１８０からデータを読み取る部位である。
また、ＲＡＭ１５０は読み出し、書き込み可能な揮発性メモリであり、ＲＯＭ１４０は読み出し専用の不揮発性メモリであり、ＨＤＤ１２０は読み出し，書き込みが可能な不揮発性メモリである。ＲＯＭ１４０，ＨＤＤ１２０には、ＣＰＵ１３０が読み出して実行するプログラム等が予め記憶されている。

また、ＲＡＭ１５０は、ＣＰＵ１３０がＲＯＭ１４０，ＨＤＤ１２０に記憶されたプログラムを実行する際に、そのプログラムを一時的に保存するための記憶領域や、作業用のデータを一時的に保存するための記憶領域として用いられる。

また、ＣＰＵ１３０は、ＯＳをＨＤＤ１２０から読み出して実行し、ＨＤＤ１２０に記録されている各種プログラムをＯＳ上のプロセスとして実行する。また、ＣＰＵ１３０は、このプロセスにおいて、必要に応じて入力装置１６０から信号の入力を受け付け、ディスプレイ１１０に映像信号を出力し、ＲＡＭ１５０，ＨＤＤ１２０に対してデータの読み出し／書き込みの制御を行う。

また、ＰＣ１００には、読取部１７０を介して記憶媒体１８０から読み取られた自動並列化コンパイラ１がインストールされており、自動並列化コンパイラ１は、ＨＤＤ１２０に保存され、ＯＳ上のプロセスとして実行されるアプリケーションの１つとなっている。

なお、この自動並列化コンパイル装置は、車載装置等といった組み込みシステム向けの並列化プログラムの開発に用いられる。しかしながら、これに限定されることは無く、例えば情報家電等といった様々な用途の組込みシステム向けの並列化プログラムの開発や、組込みシステム以外の他の用途の並列化プログラムの開発に用いることができる。

２−２．並列化の手順
本実施形態では、自動並列化コンパイラ１は、一例として、MathWork社のMatlab（登録商標），Simulink（登録商標）にてモデルベース設計により自動生成された自動車制御プログラム（逐次プログラム）から並列化プログラムを生成する。

具体的には、まず、Embedded Coderを用いて、Simulinkによりモデルベース設計された自動車制御モデルからＣ言語で記述された自動車制御プログラムが自動生成される。そして、自動並列化コンパイラ１は、自動並列化処理を行い、自動車制御プログラム２５０を解析して並列化プログラム２５１を生成する（図１８）。

自動並列化処理では、自動並列化コンパイラ１は、自動車制御プログラム２５０に対し、インライン展開と（Ｓ２００）、ローカル変数のリネームとを行う（Ｓ２０５）。そして、自動並列化コンパイラ１は、これらの処理がなされた自動車制御プログラム２５０をマクロタスクに分割し、データ依存性と制御依存性を解析してＭＦＧを生成する（Ｓ２１０）。

続くＳ２１５では、自動並列化コンパイラ１は、ＭＦＧが示す制御依存性に基づき、異なるマクロタスクに分岐するマクロタスクを始端タスクとして特定する。また、自動並列化コンパイラ１は、該始端タスクを始点として順次実行される複数の一連の処理の全てにおいて共通して実行されるマクロタスクのうち、最初に実行されるものを終端タスクとして特定する。

そして、自動並列化コンパイラ１は、特定した始端タスクと、該始端タスクを始点とする処理における終端タスクと、該始端タスクの実行後であって、該終端タスクの実行前に実行される全てのマクロタスクとを、１つのマクロタスクに融合させ（タスク融合）、Ｓ２２０に処理を移行する。

なお、タスク融合を行うことで、ＭＦＧは制御依存性が無い状態となる。
また、マクロタスクの粒度を細かくするためには、Ｓ２１５での処理のように、始端タスクを始点として順次実行される複数の一連の処理の全てにおいて共通して実行されるマクロタスクのうち、最初に実行されるマクロタスクを終端タスクとして特定するのが好適である。しかし、これに限らず、これらのマクロタスクのうち、２番目以降に実行されるいずれか一つのマクロタスクを終端タスクとして特定しても良い。

Ｓ２２０では、自動並列化コンパイラ１は、タスク融合がなされたＭＦＧに基づき、各マクロタスクの最早実行可能条件を解析し、ＭＴＧを生成する。また、自動並列化コンパイラ１は、ＭＴＧに基づきスタティックスケジューリングを行い、並列実行可能なマクロタスクを異なるＰＥに割り当て、並列化プログラム２５１を生成する（Ｓ２２５）。

なお、このとき、自動並列化コンパイラ１は、並列化プログラム２５１を様々なプラットフォームで動作させるため、自動並列化ＡＰＩ標準解釈系を用いて、自動並列化ＡＰＩが加えられた並列化プログラムをランタイムライブラリが実装された並列化プログラムに変換しても良い。

そして、自動並列化コンパイラ１は、並列化プログラム２５１からバイナリデータ２５２を生成する（Ｓ２３０）。
２−３．自動車制御プログラムの特徴
例えば、エンジン制御を行う自動車制御プログラムは、基本的に、初期化関数と、繰り返し実行される主要エンジン制御計算関数から構成される。

図１９に例示されたエンジン制御用の自動車制御プログラムは、“Model_step関数”を繰り返し実行することでリアルタイム制御が行われる。自動車制御はデッドラインが短いため、“Model_step関数”では、１周期が長くてもマイクロ秒オーダーであり、プログラムの粒度は極めて細かい。この“Model_step関数”では、Simulinkモデルに記述されたブロックに該当するすべての処理が計算される。

また、図２０は、自動車制御モデル３００，３０１と、これに基づき自動生成されたＣ言語の自動車制御プログラム３０２，３０４とを示している。図２０が示すように、例えば、モデル３０１の“Saturationブロック”は、“if”と“if else”と“else”から構成されるプログラムに変換される。また、モデル３０１の“Switchブロック”は、“if”と“else”のプログラムに変換される。

この自動車制御プログラムにおける“Model_step関数”は、この自動車制御モデル上の制御関数に対応しているため、本実施形態では、この制御関数を並列化し、高速化を行う。

また、このような自動車制御プログラムの特徴は、従来の並列化コンパイラが並列化の対象としてきたループが存在しない（或いは少ししか存在しない）という点である。そして、図２０が示すように、自動車制御では、センサー情報等によって処理を変化させる必要があるので、“Switchブロック”や“Saturationブロック”を多用して設計を行うことが多く、基本的に条件分岐文と代入文の組み合わせで構成されている。

すなわち、自動車制御プログラムには、従来行われていたループ内イタレーションレベルでの並列化が適用できない。このため、自動並列化コンパイラ１は、上述した自動並列化処理において、Simulinkモデルレベルでの並列性を粗粒度レベルタスク並列化機能により抽出する。

また、モデルベース設計された制御関数は、サブルーチン間の並列性が乏しく、並列性を細かく引き出す必要性があるため、自動並列化コンパイラ１はインライン展開（自動並列化処理のＳ２００）を行う。図２１にはインライン展開後のＭＦＧの一例が記載されている（該ＭＦＧにおけるＢＢは基本ブロックを示している）。該ＭＦＧからわかるように、モデルベース開発された逐次プログラムには、処理コストが大きい並列化可能なループが存在せず、ノード内の小円により表される条件分岐を持つ基本ブロックが多数存在する。

また、各ノードの処理時間は長くても数十クロックサイクル程度であり、大変処理が細かく、従来の手法では並列化が困難であり、オーバーヘッドを最大限抑えることが重要とある。

２−４．自動車制御プログラムのリストラクチャリング手法と並列化手法
そこで、自動並列化コンパイラ１は、Simulinkモデルから自動生成された自動車制御プログラムから十分に並列性を抽出し、よりオーバーヘッドを低くした状態で並列化が可能になるように、プログラムのリストラクチャリングを行う。

＜関数のインライン展開（自動並列化処理のＳ２００）＞
自動車制御プログラムは、処理が細かく、粗い粒度での並列化が困難であるため、制御関数内のサブルーチン内の並列性をも有効活用すべきである。このため、自動並列化コンパイラ１は、制御関数内のサブルーチンのインライン展開を行う（サブルーチンをコールする記述を、該サブルーチンにて定義されている処理の記述に置き換える）。

インライン展開が有効な例を挙げると、図２２のＭＴＧ３２０は、“sb2”と”sb3”とが依存関係を有しており、並列性が存在しない。しかし、“sb2”，“sb3”のＭＴＧ３２１，３２２が示すように、これらのサブルーチンの内部処理には並列性があるため、“sb2”と“sb3”をインライン展開することにより、これらのサブルーチンの並列性を利用することができる。なお、図２３は、“sb2”と“sb3”をインライン展開した後のＭＴＧ３２３を示している。

＜ローカル変数のリネーミング（自動並列化処理のＳ２０５）＞
Simulinkモデルから自動生成された自動車制御プログラムでは、ＲＯＭ使用量削減のため、多くの箇所でローカル変数が繰り返し使用されている。一例として、図２４に記載の自動車制御プログラムでは、複数の箇所３３０，３３１でローカル変数“tmp”が繰り返し使用されている。

これにより、並列性解析の際にデータ依存があると特定され、並列性が十分引き出せなくなってしまう。そこで、自動並列化処理のＳ２０５では、使い回しされているローカル変数のリネームを行う。

具体的には、自動並列化コンパイラ１は、制御関数内において、同一名称のローカル変数が用いられている複数の処理ブロックを特定すると共に、特定した各処理ブロックにおいて独自の名称のローカル変数が用いられるよう、自動車制御プログラムを改変する。

なお、処理ブロックとは、例えば、ループ処理や、if文やswitch-case文等の分岐処理のステートメントと、これに付随する代入文等から構成される記述の集合体であっても良い。また、このほかにも、例えば、自動車制御プログラムを生成したSimulinkモデルにおける各ブロックに対応する記述の集合体を、処理ブロックとしても良い。

図２４の自動車制御プログラムを例に挙げると、if-else文からなるステートメントと代入文及び関数コールから構成される処理ブロック３３０，３３１では、同一名称のローカル変数“tmp”が用いられている。リネームにより、例えば、処理ブロック３３０にてアクセスされるローカル変数の名称が“tmp1”に、処理ブロック３３１にてアクセスされるローカル変数の名称が“tmp2”に変更される。

なお、Embedded Coderを用いてSimulinkモデルから自動車制御プログラムを自動生成する際、Embedded Coderをローカル変数の使い回しがされない設定（各ブロックに対応する記述毎に別の名称のローカル変数が用いられる設定）としても良い。これにより、Ｓ２０５の処理を行わなくても、マクロタスク間に不要なデータ依存が生じてしまうことを防ぐことができる。

＜条件分岐隠蔽のためのタスク融合（自動並列化処理のＳ２１５）＞
上述したように、自動車制御プログラムにはループ構造が存在しないため、近細粒度並列化か粗粒度タスク並列化を適用することが考えられるが、実行オーバーヘッドを相対的に小さく抑えるため、自動並列化コンパイラ１は、粗粒度タスク並列化を適用する。

また、自動車制御プログラムでは、各マクロタスクのコストは数１０クロック程度であるが、自動並列化コンパイラ１によりダイナミックスケジューリングを行った場合には、通常数１０から数１００クロックのオーバーヘッドが生じる。このため、ダイナミックスケジューリングは、自動車制御プログラムには不向きである。

しかしながら、条件分岐を持つマクロタスクは、その実行時に動的に分岐先が決定されるため、そのままでは、コンパイル時にプロセッサコアを割り当てるスタティックスケジューリングが適用できないという問題がある。

そこで、自動並列化処理のＳ２１５では、自動並列化コンパイラ１は、タスク融合アルゴリズムにより、条件分岐をもつマクロタスクと、その分岐先のマクロタスクまでを１つの粗粒度タスク（Blockタスク） に融合するタスク融合を行う。

具体的には、ＭＦＧ３５０（図２５参照）からＭＴＧ３５１（図２６参照）が生成されるが、該ＭＦＧ３５０に対してタスク融合を行うと、ＭＦＧ３５２（図２７参照）が生成され、ＭＦＧ３５２からは、ＭＴＧ３５３（図２８参照）が生成される。

ＭＦＧ３５０に対するタスク融合では、条件分岐を有する“bb1”，“bb6”が始端タスクとして特定される。
また、“bb1”を始点とする一連の処理として、“bb1”，“bb2”，“bb4”…と、“bb1”，“bb3”，“bb4”…とが特定される。また、これらの一連の処理において共通して実行されるマクロタスクのうち、最初に実行される“bb4”が、終端タスクとして特定される。

そして、始端タスクである“bb1”と、終端タスクである“bb4”と、“bb1”の後であって、“bb4”の前に実行される“bb2”，“bb3”とが、１つのマクロタスク（ＭＦＧ３５２の“Block1”）に融合される。

また、ＭＦＧ３５０に対するタスク融合では、“bb6”を始点とする一連の処理として、“bb6”，“bb7”，“bb12”…と、“bb6”，“bb8”，“bb10”，“bb11”，“bb12”…と、“bb6”，“bb8”，“bb9”，“bb11”，“bb12”…と、が特定される。また、これらの一連の処理において共通して実行されるマクロタスクのうち、最初に実行される“bb12”が、終端タスクとして特定される。

そして、始端タスクである“bb6”と、終端タスクである“bb12”と、“bb6”の後であって、“bb12”の前に実行される“bb7〜11”とが、１つのマクロタスク（ＭＦＧ３５２の“Block3”）に融合される。

タスク融合により生成されたＭＦＧ３５２には条件分岐が存在しない（制御依存性が存在しない）ため、スタティックスケジューリングが可能となる。
３．性能評価について
次に、本実施形態の自動並列化コンパイラ１により生成された並列化プログラムにより動作するマルチコアプロセッサが搭載された車載装置の性能評価の結果について説明する。

３−１．車載装置の構成について
まず、自動並列化コンパイラ１により生成された並列化プログラムにより動作するエンジン制御ＥＣＵ４００の構成について説明する（図２９参照）。

エンジン制御ＥＣＵ４００は、ＲＯＭ４１０，ＲＡＭ４２０，通信部４３０，マルチコアプロセッサ４４０，センサ部４５０，入出力ポート４６０等を備える。
ＲＯＭ４１０は、自動並列化コンパイラ１により生成された並列化プログラムのバイナリデータを保存する部位であり、マルチコアプロセッサ４４０は、該バイナリデータに従い動作し、エンジン制御ＥＣＵ４００を統括制御する。

また、ＲＡＭ４２０は、マルチコアプロセッサ４４０によりアクセスされる部位である。
また、通信部４３０は、車内ＬＡＮ等を介して接続された他のＥＣＵと通信を行う部位である。

また、センサ部４５０は、エンジン４７０の状態を検出するための各種センサから構成される部位である。
また、入出力ポート４６０は、エンジン４７０を制御するための各種信号の送受信を行う部位である。

また、マルチコアプロセッサ４４０は、複数のＰＥ４４１，４４２を有しており、例えば、情報家電用マルチコアであるＲＰ２や、ルネサスエレクトロニクス株式会社のＶ８５０Ｅ２Ｒ等であっても良い。

ＲＰ２は、ＳＨ４ａ（ＳＨ−Ｘ３）コアを８個搭載したホモジニアスマルチコアであり、各コアには、中央演算処理装置（ＣＰＵ），ローカルプログラムメモリ（ＬＰＭ），ローカルデータメモリ（ＬＤＭ），分散共有メモリ（ＤＳＭ）が設けられている。また、各コアには、ＣＰＵと非同期に動作し、データ転送を行うことができるデータ転送ユニット（ＤＴＵ）が設けられている。

なお、エンジン制御ＥＣＵ４００に限らず、マルチコアプロセッサが搭載された他のＥＣＵ（例えば、ナビゲーション装置等）を、自動並列化コンパイラ１により生成された並列化プログラムにより動作させても良い。また、車載装置に限らず、マルチコアプロセッサが搭載された情報家電等の電子装置を、自動並列化コンパイラ１により生成された並列化プログラムにより動作させても良い。

３−２．エンジン制御ＥＣＵの評価結果について
エンジン制御ＥＣＵ４００の制御システムのモデルは、ＥＣＵモデル，Driverモデル，Ｃａｒモデル，Sensorモデルの４つのサブシステムを有している。マルチコアプロセッサ４４０としてＲＰ２とＶ８５０Ｅ２Ｒを用いた場合における、エンジン制御ＥＣＵ４００の制御システム全体の性能評価や、各サブシステムの性能評価の結果について説明する。

＜ＲＰ２での性能評価＞
まず、ＥＣＵモデル，Driverモデル，Sensorモデル，Ｃａｒモデルを、２コアにより並列動作するＲＰ２と、１コアにより逐次動作するＲＰ２により動作させた。なお、これらのモデルから生成されたプログラムには、サイズ優先の最適化が施されている。

ＥＣＵモデルに関しては、１コアのＰＲ２では１周期あたりの実行時間が１１９μｓであったのに対し、２コアのＰＲ２では１周期あたりの実行時間が６３μｓに短縮された。また、速度向上率に関しては、２コアのＰＲ２は、１コアのＰＲ２に比べ、１．８９倍の性能向上が得られた。

また、Driverモデルに関しては、１コアのＰＲ２では１周期あたりの実行時間が４１μｓであったのに対し、２コアのＰＲ２では１周期あたりの実行時間が２７μｓに短縮された。また、速度向上率に関しては、２コアのＰＲ２は、１コアのＰＲ２に比べ、１．５２倍の性能向上が得られた。

また、Sensorモデルに関しては、１コアのＰＲ２では１周期あたりの実行時間が４０μｓであったのに対し、２コアのＰＲ２では１周期あたりの実行時間が２６μｓに短縮された。また、速度向上率に関しては、２コアのＰＲ２は、１コアのＰＲ２に比べ、１．５２倍の性能向上が得られた。

また、Ｃａｒモデルに関しては、１コアのＰＲ２では１周期あたりの実行時間が２３８２μｓであったのに対し、２コアのＰＲ２では１周期あたりの実行時間が１２９１μｓに短縮された。また、速度向上率に関しては、２コアのＰＲ２は、１コアのＰＲ２に比べ、１．８４倍の性能向上が得られた。

次に、エンジン制御ＥＣＵ４００の制御システム全体を、４コアにより並列動作するＲＰ２と、２コアにより並列動作するＲＰ２と、１コアにより逐次動作するＲＰ２により動作させた。なお、制御システム全体のモデルから生成されたプログラムには、サイズ優先の最適化が施されている。

その結果、１コアのＰＲ２では１周期あたりの実行時間が４１６１μｓであったのに対し、２コアのＰＲ２では１周期あたりの実行時間が２３９７μｓに、４コアのＰＲ２では１周期あたりの実行時間が１２７３μｓに短縮された。また、速度向上率に関しては、２コアのＰＲ２は、１コアのＰＲ２に比べ１．７４倍の性能向上が得られ、４コアのＰＲ２は、１コアのＰＲ２に比べ３．２７倍の性能向上が得られた。

＜Ｖ８５０Ｅ２Ｒでの性能評価＞
また、ＥＣＵモデルを、２コアにより並列動作するＶ８５０Ｅ２Ｒと、１コアにより逐次動作するＶ８５０Ｅ２Ｒにより動作させた。なお、ＥＣＵモデルから生成されたプログラムには、サイズ優先の最適化が施されている。

その結果、速度向上率に関して、２コアのＶ８５０Ｅ２Ｒは、１コアのＶ８５０Ｅ２Ｒに比べ、１．９１倍の性能向上が得られた。
３−３．エンジン燃料噴射制御モデルでの評価結果について
また、自動並列化コンパイラ１によりエンジン燃料噴射制御モデルから生成された並列化プログラムを、ＲＰ２とＶ８５０Ｅ２Ｒで動作させた場合の性能評価の結果について説明する。

＜ＲＰ２での性能評価＞
エンジン燃料噴射制御モデルを、４コアにより並列動作するＲＰ２と、２コアにより並列動作するＲＰ２と、１コアにより逐次動作するＲＰ２により動作させた。なお、エンジン燃料噴射制御モデルから生成されたプログラムには、サイズ優先の最適化が施されている。

その結果、１コアのＰＲ２では１周期あたりの実行時間が１５７μｓであったのに対し、２コアのＰＲ２では１周期あたりの実行時間が８７μｓに、４コアのＰＲ２では１周期あたりの実行時間が４２μｓに短縮された。また、速度向上率に関しては、２コアのＰＲ２は、１コアのＰＲ２に比べ１．８１倍の性能向上が得られ、４コアのＰＲ２は、１コアのＰＲ２に比べ３．７６倍の性能向上が得られた。

＜Ｖ８５０Ｅ２Ｒでの性能評価＞
また、エンジン燃料噴射制御モデルを、２コアにより並列動作するＶ８５０Ｅ２Ｒと、１コアにより逐次動作するＶ８５０Ｅ２Ｒにより動作させた。なお、エンジン燃料噴射制御モデルから生成されたプログラムには、サイズ優先の最適化が施されている。

その結果、速度向上率に関して、２コアのＶ８５０Ｅ２Ｒは、１コアのＶ８５０Ｅ２Ｒに比べ、１．７９倍の性能向上が得られた。
［他の実施形態］
（１）本実施形態の自動並列化コンパイラ１は、自動並列化処理のＳ２００にて逐次プログラムのインライン展開を行うと共に、Ｓ２０５にてローカル変数のリネームを行うが、これらの処理の双方または一方を行わない構成としても良い。このような場合であっても、逐次プログラムの構造によっては、同様の効果が得られる。

（２）本実施形態の自動並列化コンパイラ１は、生成した並列化プログラムに対し、投機的実行を行うための最適化を行っても良い。こうすることにより、より一層、並列化プログラムの性能の向上を図ることができる。

［特許請求の範囲との対応］
上記実施形態の説明で用いた用語と、特許請求の範囲の記載に用いた用語との対応を示す。

自動並列化処理のＳ２００が並列化コンパイル方法の置換手順の一例に、Ｓ２０５がリネーム手順の一例に相当する。
また、Ｓ２１０が、並列化コンパイル方法，並列化コンパイラの分割手順と、並列化コンパイル装置の分割手段の一例に、Ｓ２１５が、並列化コンパイル方法，並列化コンパイラの特定手順，融合手順と、並列化コンパイル装置の特定手段，融合手段の一例に相当に相当する。

また、Ｓ２２０が、並列化コンパイル方法，並列化コンパイラの抽出手順と、並列化コンパイル装置の抽出手段の一例に、Ｓ２２５が、並列化コンパイル方法，並列化コンパイラのスケジューリング手順と、並列化コンパイル装置のスケジューリング手段の一例に相当する。

また、Ｓ２２５，Ｓ２３０が、並列化コンパイル方法，並列化コンパイラの生成手順と、並列化コンパイル装置の生成手段の一例に相当する。
また、ＰＥ，ＰＧ，プロセッサコアが、プロセッサユニットの一例に相当する。

また、エンジン制御ＥＣＵ４００が車載装置の一例に相当する。

１…自動並列化コンパイラ、３…ＦＥ、４…中間言語、５…ＭＰ、６…中間言語、７…ＢＥ、９…並列化ＡＰＩ、５０…マルチコアアーキテクチャ、７０…自動並列化ＡＰＩ標準解釈系、１００…ＰＣ、１１０…ディスプレイ、１２０…ＨＤＤ、１３０…ＣＰＵ、１４０…ＲＯＭ、１５０…ＲＡＭ、１６０…入力装置、１７０…読取部、１８０…記憶媒体、２５０…自動車制御プログラム、４００…エンジン制御ＥＣＵ、４１０…ＲＯＭ、４２０…ＲＡＭ、４３０…通信部、４４０…マルチコアプロセッサ、４５０…センサ部、４６０…入出力ポート。

Claims (6)

1. シングルプロセッサシステムにより実行される車載装置向けの組込みシステム用の逐次プログラムを、予め定められた方法に従い複数のマクロタスクに分割する分割手順（Ｓ２１０）と、
   前記マクロタスク間の制御依存性に基づき、異なる前記マクロタスクに分岐する処理を有する前記マクロタスクを始端タスクとして特定すると共に、該始端タスクを始点として順次実行される複数の一連の処理の全てにおいて共通して実行される前記マクロタスクのうちのいずれか一つを終端タスクとして特定する特定手順（Ｓ２１５）と、
   前記特定手順により特定された前記始端タスクと、該始端タスクを始点とする処理における前記終端タスクと、該始端タスクの実行後であって、該終端タスクの実行前に実行される全ての前記マクロタスクとを、新たな前記マクロタスクとして融合させる融合手順（Ｓ２１５）と、
   前記融合手順による融合がなされた後の前記マクロタスク間のデータ依存性に基づき、車載装置に搭載されたマルチプロセッサシステムを構成する複数のプロセッサユニットにより並列実行可能な前記マクロタスクを抽出する抽出手順（Ｓ２２０）と、
   並列実行可能な前記マクロタスクが異なる前記プロセッサユニットにより並列的に実行されるよう、それぞれの前記マクロタスクをいずれかの前記プロセッサユニットに割り当てるスタティックスケジューリングを行うスケジューリング手順（Ｓ２２５）と、
   前記スタティックスケジューリングの結果に基づき、前記マルチプロセッサシステムにより実行される並列化プログラムを生成する生成手順（Ｓ２２５，Ｓ２３０）と、
   を有することを特徴とする並列化コンパイル方法。
2. 請求項１に記載の並列化コンパイル方法において、
   前記逐次プログラムにおける関数をコールする記述を、該関数における処理の記述に置き換えるインライン展開を行う置換手順（Ｓ２００）をさらに備え、
   前記分割手順では、前記インライン展開がなされた前記逐次プログラムを、前記マクロタスクに分割すること、
   を特徴とする並列化コンパイル方法。
3. 請求項１または請求項２に記載の並列化コンパイル方法において、
   前記逐次プログラムに記述された関数における特定の目的を実現するための記述の集まりを処理ブロックとし、関数における同一名称のローカル変数が用いられた異なる前記処理ブロックを特定すると共に、これらの処理ブロックにおいて異なる名称のローカル変数が用いられるよう、該関数の記述を変更するリネーム手順（Ｓ２０５）と、
   前記特定手順では、前記リネーム手順によりローカル変数の名称の変更がなされた後に、前記マクロタスク間の制御依存性を解析し、前記始端タスクと前記終端タスクとを特定すること、
   を特徴とする並列化コンパイル方法。
4. シングルプロセッサシステムにより実行される車載装置向けの組込みシステム用の逐次プログラムを、予め定められた方法に従い複数のマクロタスクに分割する分割手順（Ｓ２１０）と、
   前記マクロタスク間の制御依存性に基づき、異なる前記マクロタスクに分岐する処理を有する前記マクロタスクを始端タスクとして特定すると共に、該始端タスクを始点として順次実行される複数の一連の処理の全てにおいて共通して実行される前記マクロタスクのうちのいずれか一つを終端タスクとして特定する特定手順（Ｓ２１５）と、
   前記特定手順により特定された前記始端タスクと、該始端タスクを始点とする処理における前記終端タスクと、該始端タスクの実行後であって、該終端タスクの実行前に実行される全ての前記マクロタスクとを、新たな前記マクロタスクとして融合させる融合手順（Ｓ２１５）と、
   前記融合手順による融合がなされた後の前記マクロタスク間のデータ依存性に基づき、車載装置に搭載されたマルチプロセッサシステムを構成する複数のプロセッサユニットにより並列実行可能な前記マクロタスクを抽出する抽出手順（Ｓ２２０）と、
   並列実行可能な前記マクロタスクが異なる前記プロセッサユニットにより並列的に実行されるよう、それぞれの前記マクロタスクをいずれかの前記プロセッサユニットに割り当てるスタティックスケジューリングを行うスケジューリング手順（Ｓ２２５）と、
   前記スタティックスケジューリングの結果に基づき、前記マルチプロセッサシステムにより実行される並列化プログラムを生成する生成手順（Ｓ２２５，Ｓ２３０）と、
   をコンピュータに実行させることを特徴とする並列化コンパイラ。
5. シングルプロセッサシステムにより実行される車載装置向けの組込みシステム用の逐次プログラムを、予め定められた方法に従い複数のマクロタスクに分割する分割手段（Ｓ２１０）と、
   前記マクロタスク間の制御依存性に基づき、異なる前記マクロタスクに分岐する処理を有する前記マクロタスクを始端タスクとして特定すると共に、該始端タスクを始点として順次実行される複数の一連の処理の全てにおいて共通して実行される前記マクロタスクのうちのいずれか一つを終端タスクとして特定する特定手段（Ｓ２１５）と、
   前記特定手段により特定された前記始端タスクと、該始端タスクを始点とする処理における前記終端タスクと、該始端タスクの実行後であって、該終端タスクの実行前に実行される全ての前記マクロタスクとを、新たな前記マクロタスクとして融合させる融合手段（Ｓ２１５）と、
   前記融合手段による融合がなされた後の前記マクロタスク間のデータ依存性に基づき、車載装置に搭載されたマルチプロセッサシステムを構成する複数のプロセッサユニットにより並列実行可能な前記マクロタスクを抽出する抽出手段（Ｓ２２０）と、
   並列実行可能な前記マクロタスクが異なる前記プロセッサユニットにより並列的に実行されるよう、それぞれの前記マクロタスクをいずれかの前記プロセッサユニットに割り当てるスタティックスケジューリングを行うスケジューリング手段（Ｓ２２５）と、
   前記スタティックスケジューリングの結果に基づき、前記マルチプロセッサシステムにより実行される並列化プログラムを生成する生成手段（Ｓ２２５，Ｓ２３０）と、
   を備えることを特徴とする並列化コンパイル装置。
6. シングルプロセッサシステムにより実行される車載装置向けの組込みシステム用の逐次プログラムを、予め定められた方法に従い複数のマクロタスクに分割する分割手順（Ｓ２１０）と、
   前記マクロタスク間の制御依存性に基づき、異なる前記マクロタスクに分岐する処理を有する前記マクロタスクを始端タスクとして特定すると共に、該始端タスクを始点として順次実行される複数の一連の処理の全てにおいて共通して実行される前記マクロタスクのうちのいずれか一つを終端タスクとして特定する特定手順（Ｓ２１５）と、
   前記特定手順により特定された前記始端タスクと、該始端タスクを始点とする処理における前記終端タスクと、該始端タスクの実行後であって、該終端タスクの実行前に実行される全ての前記マクロタスクとを、新たな前記マクロタスクとして融合させる融合手順（Ｓ２１５）と、
   前記融合手順による融合がなされた後の前記マクロタスク間のデータ依存性に基づき、車載装置に搭載されたマルチプロセッサシステムを構成する複数のプロセッサユニットにより並列実行可能な前記マクロタスクを抽出する抽出手順（Ｓ２２０）と、
   並列実行可能な前記マクロタスクが異なる前記プロセッサユニットにより並列的に実行されるよう、それぞれの前記マクロタスクをいずれかの前記プロセッサユニットに割り当てるスタティックスケジューリングを行うスケジューリング手順（Ｓ２２５）と、
   前記スタティックスケジューリングの結果に基づき、前記マルチプロセッサシステムにより実行される並列化プログラムを生成する生成手順（Ｓ２２５，Ｓ２３０）と、
   を有する並列化コンパイル方法により生成された前記並列化プログラムにより動作する前記マルチプロセッサシステムを備えることを特徴とする車載装置（４００）。