| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
条件コードステータスについて説明する。
ファイル ‘conditions.h’ で、変数 cc_status を
定義している。これは、条件コードがどのように計算されるかを記述している
(条件コードを設定した命令によって条件コードの解釈が異なる場合)。
この変数は、条件コードが現在元にしている RTL 式と、色々な標準の
フラグを含んでいる。
場合によっては、機種固有のフラグをマシン記述ヘッダファイルで
追加で定義しなければならないこともある。
また、機種固有の情報を CC_STATUS_MDEP を定義することで追加することが
できる。
CC_STATUS_MDEPcc_status の mdep 成分を宣言するのに使われる
データ型についての C のコード。
デフォルトは int になる。
このマクロは、cc0 を使用しない機種では使われない。
CC_STATUS_MDEP_INITmdep フィールドを「空」に初期化する C の式。
デフォルトの定義は何もしない。何故なら、ほとんどの機種では
このフィールドは使わないからである。
このフィールドを使う場合には、恐らくこのマクロを定義して初期化を
すべきであろう。
このマクロは、cc0 を使用しない機種では使われない。
NOTICE_UPDATE_CC (exp, insn)本体が exp である insn insn に対して
cc_status の成分を適切に設定する、C の複文。
このマクロは、条件コードを設定する insn を認識する責任を負う。
これには、明示的に (cc0) を設定するものだけでなく、
他の処理の副産物として条件コードを設定するものも含まれる。
このマクロは、cc0 を使用しない機種では使われない。
条件コードは設定しないが他のマシンレジスタをいじる命令があるなら、
このマクロで、条件コードがそれを反映するように記録されている式を
それらの命令が無効にするかどうかを検査しなければならない。
例えば、68000 では、アドレスレジスタにストアする命令は
条件コードを設定しない。これは普通 NOTICE_UPDATE_CC が
そういう命令に対して cc_status を変えないままにしておくことが
可能であるということを意味する。だが、直前の命令が ‘a4@(102)’ という
位置に基づいて条件コードを設定し、現在の命令が新しい値を ‘a4’ に
ストアするとしよう。条件コードはこれにより変更されないものの、
それが ‘a4@(102)’ の内容を反映しているというのはもはや真ではない。
このため、NOTICE_UPDATE_CC は、この場合 cc_status を
変更することにより、条件コード値については何もわからないということを
言わなければならない。
NOTICE_UPDATE_CC は、覗き穴最適化の結果を扱う準備を
するように定義しなければならない。
覗き穴最適化の結果とは、そのパターンが様々な、reg や mem、
あるいは単なるオペランドである定数を含む parallel RTX である
ような insn 群である。
これらの insn の RTL 構造は、その insn が実際に何をするのかを表すのには
充分ではない。NOTICE_UPDATE_CC が、こういう insn に対して
なすべきことは、単に CC_STATUS_INIT を実行することである。
NOTICE_UPDATE_CC の可能な定義の一つは、例えば ‘cc’ という
名前の属性(see section 命令の属性)を見る関数を呼び出すことである。
これにより、パターンについての詳細な情報を二箇所、すなわち
‘md’ ファイルと NOTICE_UPDATE_CC に置くのを避けることができる。
EXTRA_CC_MODESレジスタにある条件コード値の追加のモードに使われる名前のリストである。
このリストの名前は、enum machine_mode に追加され、その全てが
クラス MODE_CC を持つ。規約により、これらの名前は ‘CC’ で
始まり、‘mode’ で終わるようにする。
このマクロを定義するのは、cc0 を使わない機種で、しかも追加のモードが
必要な場合に限ること。
EXTRA_CC_NAMESEXTRA_CC_MODES に列挙したモードの名前を与える C の文字列の
リスト。例えば、SPARC では、このマクロと EXTRA_CC_MODES を
以下のように定義している。
#define EXTRA_CC_MODES CC_NOOVmode, CCFPmode, CCFPEmode #define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE" |
このマクロは、EXTRA_CC_MODES が定義されていなければ必要と
されない。
SELECT_CC_MODE (op, x, y)クラス MODE_CC のあるモードで、比較演算コード op を
RTX x と y に適用したときに使われるものを返す。
例えば、SPARC では、SELECT_CC_MODE は、以下のように
定義されている(see section ジャンプ命令のパターンを定義する でこの定義の理由を説明している)。
#define SELECT_CC_MODE(OP,X,Y) \
(GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \
? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \
: ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
|| GET_CODE (X) == NEG) \
? CC_NOOVmode : CCmode))
|
このマクロは、EXTRA_CC_MODES が定義されていなければ、
定義する必要はない。
CANONICALIZE_COMPARISON (code, op0, op1)機種によっては、可能な比較が全ては定義されていないものがあるが、
無効な比較を有効なものに変換することができる。
例えば、Alpha には GT の比較がないが、
代わりに LT の比較を使って、オペランドの順番を入れ替えることができる。
そういう機種では、このマクロを一個の C の文として定義し、 必要な変換を行なうようにする。 code は、最初の比較コードであり、op0 と op1 は それぞれ比較の左オペランドと右オペランドである。 必要に応じて、code と op0、op1 を更新すべきである。
GNU CC は、このマクロから生じる比較が有効であるとは仮定しないが、 結果の insn が ‘md’ ファイルにあるパターンにマッチするかどうかは 分かる。
比較のコードやオペランドを変更することが全くないのなら、このマクロを 定義する必要はない。
REVERSIBLE_CC_MODE (mode)モードが mode の比較を反転することが常に安全に行なえるのなら、
値が 1 となる C の式である。
SELECT_CC_MODE が浮動小数点の不等性の比較に対して、
常に mode を返すことができるなら、
REVERSIBLE_CC_MODE (mode) はゼロでなければならない。
このマクロが常にゼロを返すか浮動小数点形式が IEEE_FLOAT_FORMAT
以外なら、このマクロを定義する必要はない。
例えば、以下に Sparc で使われている定義を示す。
浮動小数点数の不等性の比較は常に CCFPEmode で与えられる。
#define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode) |
This document was generated
using texi2html 1.78.