全ての RTL の定義は gcc/rtl.def に定義されています。例えば insn の定義は下記のとおりです。
/* An instruction that cannot jump. */
DEF_RTL_EXPR(INSN, "insn", "uuBeiie", RTX_INSN)
何となくわかるけど、何だこれ?と思いますよね、私は思いました。それもそのはずで、実はこのファイルは単体では意味をなさず、C ファイルから何度も再利用されるからです。C ファイルから rtl.def をインクルードして使いますが、その際に DEF_RTL_EXPR() の意味が変わります。
比較的わかりやすい例を挙げるとしたら、gcc/rtl.c の rtx_format の定義です。DEF_RTL_EXPR() を定義してから #include "rtl.def" を行う様子がわかるかと思います。
/* Indexed by rtx code, gives a sequence of operand-types for
rtx's of that code. The sequence is a C string in which
each character describes one operand. */
const char * const rtx_format[NUM_RTX_CODE] = {
/* "*" undefined.
can cause a warning message
"0" field is unused (or used in a phase-dependent manner)
prints nothing
"i" an integer
prints the integer
"n" like "i", but prints entries from `note_insn_name'
"w" an integer of width HOST_BITS_PER_WIDE_INT
prints the integer
"s" a pointer to a string
prints the string
"S" like "s", but optional:
the containing rtx may end before this operand
"T" like "s", but treated specially by the RTL reader;
only found in machine description patterns.
"e" a pointer to an rtl expression
prints the expression
"E" a pointer to a vector that points to a number of rtl expressions
prints a list of the rtl expressions
"V" like "E", but optional:
the containing rtx may end before this operand
"u" a pointer to another insn
prints the uid of the insn.
"b" is a pointer to a bitmap header.
"B" is a basic block pointer.
"t" is a tree pointer.
"r" a register.
"p" is a poly_uint16 offset. */
#define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS) FORMAT ,
#include "rtl.def" /* rtl expressions are defined here */
#undef DEF_RTL_EXPR
};
この rtx_format の場合は、第 3引数(FORMAT)とカンマを残して、他は無視するように DEF_RTL_EXPR() を定義しています。
コメントなどを無視して考えると rtl.def をインクルードしたあとは、コードは下記のようになります。
const char * const rtx_format[NUM_RTX_CODE] = {
DEF_RTL_EXPR(UNKNOWN, "UnKnown", "*", RTX_EXTRA)
DEF_RTL_EXPR(VALUE, "value", "0", RTX_OBJ)
DEF_RTL_EXPR(DEBUG_EXPR, "debug_expr", "0", RTX_OBJ)
...
};
マクロ DEF_RTL_EXPR() の展開後はこうなります。
const char * const rtx_format[NUM_RTX_CODE] = {
"*",
"0",
"0",
...
};
最終的に rtx_format は文字列の配列になります。
私も rtl.def の用途全てを理解しているわけではなく、全てを説明することもできないので、またわかったら書くことにします。
GCC のインラインアセンブラでは __asm__("ins %0" : "=r"(aaa) : : ); のように、"=r" という不思議な文字列が出てきます。
これは constraints と呼ばれ(GCC のマニュアルへのリンク)、引数がレジスタ(r)なのかメモリアドレス(m)なのか、書き換えられるのか(=)などを説明しています。
どんな文字でも書けるわけではなく、変な文字(例えば 'v')を指定すると「impossible constraint in 'asm'」と怒られます。これは一体どこでチェックしているのでしょう?また、どうやって足せばよいでしょうか?
このエラーを出すのは、パスでいうと 234r.vregs です。
ちなみに build_gcc というディレクトリ名は GCC のビルドディレクトリのことです。GCC は自動生成コードをかなりの量出力するので、そちらも合わせて見る必要があります。
// gcc/function.c
static void
instantiate_virtual_regs_in_insn (rtx_insn *insn)
{
...
if (asm_noperands (PATTERN (insn)) >= 0)
{
if (!check_asm_operands (PATTERN (insn))) //★★このエラーチェックに引っかかっている
{
error_for_asm (insn, "impossible constraint in %<asm%>"); //★★このエラーメッセージが出ている
// gcc/recog.c
int
check_asm_operands (rtx x)
{
...
for (i = 0; i < noperands; i++)
{
const char *c = constraints[i];
if (c[0] == '%')
c++;
if (! asm_operand_ok (operands[i], c, constraints)) //★★このエラーチェックに引っかかっている
return 0;
}
このチェックは何をしているのかというと、lookup_constraint() で文字(例えば 'v')をテーブルから探し、constraint の種類に変換します。未知の文字の場合は CONSTRAINT_UNKNOWN になります。
次に get_constraint_type() でどのカテゴリに属するか見ます。この関数はおかしくて、なぜか CONSTRAINT__UNKNOWN を CT_REGISTER と判定します。レジスタじゃないですよね?意味不明です。
// gcc/recog.c
int
asm_operand_ok (rtx op, const char *constraint, const char **constraints)
{
int result = 0;
...
while (*constraint)
{
enum constraint_num cn;
char c = *constraint;
int len;
switch (c)
{
...
default:
cn = lookup_constraint (constraint); //★★文字から constraint_num に変換
// 未知の文字の場合 CONSTRAINT__UNKNOWN になる
switch (get_constraint_type (cn))
{
case CT_REGISTER: //★★なぜかここに行く
if (!result
&& reg_class_for_constraint (cn) != NO_REGS //★★レジスタの constraint が NO_REGS になると NG
&& GET_MODE (op) != BLKmode
&& register_operand (op, VOIDmode))
result = 1;
break;
// build_gcc/gcc/tm-preds.h
static inline enum constraint_num
lookup_constraint (const char *p)
{
unsigned int index = lookup_constraint_array[(unsigned char) *p]; //★★この配列がカギ
return (index == UCHAR_MAX
? lookup_constraint_1 (p)
: (enum constraint_num) index);
}
enum constraint_num
{
CONSTRAINT__UNKNOWN = 0,
CONSTRAINT_r,
CONSTRAINT_f,
...
static inline enum constraint_type
get_constraint_type (enum constraint_num c)
{
if (c >= CONSTRAINT_p)
{
if (c >= CONSTRAINT_G)
return CT_FIXED_FORM;
return CT_ADDRESS;
}
if (c >= CONSTRAINT_m)
return CT_MEMORY;
if (c >= CONSTRAINT_I)
return CT_CONST_INT;
return CT_REGISTER; //★★c が CONSTRAINT__UNKNOWN つまり 0 の場合、どれにも当てはまらず CT_REGISTER と判断される
}
// build_gcc/insn-preds.c
const unsigned char lookup_constraint_array[] = {
CONSTRAINT__UNKNOWN,
CONSTRAINT__UNKNOWN,
...
MIN ((int) CONSTRAINT_r, (int) UCHAR_MAX),
MIN ((int) CONSTRAINT_s, (int) UCHAR_MAX),
CONSTRAINT__UNKNOWN,
CONSTRAINT__UNKNOWN,
CONSTRAINT__UNKNOWN, //★★'v' は未定義、未知の文字の場合は全て CONSTRAINT__UNKNOWN になる
CONSTRAINT__UNKNOWN,
...
// build_gcc/gcc/tm-preds.h
static inline enum reg_class
reg_class_for_constraint (enum constraint_num c)
{
if (insn_extra_register_constraint (c))
return reg_class_for_constraint_1 (c); //★★ここで見つからないと NO_REGS が返されて NG
return NO_REGS;
}
// build_gcc/gcc/insn-preds.c
enum reg_class
reg_class_for_constraint_1 (enum constraint_num c)
{
switch (c)
{
case CONSTRAINT_r: return GENERAL_REGS;
case CONSTRAINT_f: return TARGET_HARD_FLOAT ? FP_REGS : NO_REGS;
case CONSTRAINT_j: return SIBCALL_REGS;
case CONSTRAINT_l: return JALR_REGS;
default: break; //★★CONSTRAINT__UNKNOWN はどの case にも当てはまらないので NO_REGS が返されて NG
}
return NO_REGS;
}
明らかにレジスタとは思えない CONSTRAINT__UNKNOWN が返ってきますが、なぜか CT_REGISTER だと思って処理し始め、最終的にエラーとして弾きます。結果オーライですがこれで良いんでしょうか。GCC のコードは訳がわかりません……。
では v を正当な constraint の一員にするにはどうしたら良いでしょうか?
第一歩としては GCC の config ディレクトリの下にある *.md ファイル(Markdown ではなく Machine Descriptor です)を編集します。
;; config/riscv/riscv.md
(include "predicates.md")
(include "constraints.md")
;; config/riscv/constraints.md
(define_register_constraint "v" "TARGET_VECTOR ? VP_REGS : NO_REGS"
"A vector register (if available).")
これを足すと(他にも色々やらないといけないんですけど)、先程の reg_class_for_constraint_1() に変化が生じます。
// build_gcc/gcc/insn-preds.c
enum reg_class
reg_class_for_constraint_1 (enum constraint_num c)
{
switch (c)
{
case CONSTRAINT_r: return GENERAL_REGS;
case CONSTRAINT_f: return TARGET_HARD_FLOAT ? FP_REGS : NO_REGS;
case CONSTRAINT_j: return SIBCALL_REGS;
case CONSTRAINT_v: return TARGET_VECTOR ? VP_REGS : NO_REGS; //★★これが足されて通過するようになる
case CONSTRAINT_l: return JALR_REGS;
default: break;
}
return NO_REGS;
}
GCC はこの手のピタゴラスイッチの塊で、何を変えると望みの機能が実装できるか、全くわかりません。こんなもの良くメンテナンスできるなあ、と思います。
ASUS TinkerBoard で動かしている linux-next を最新版に更新したところ、下記のようなエラーを出力して起動しなくなりました。
[ 0.000000] __clk_core_init: Failed to get phase for clk 'sdmmc_drv' [ 0.000000] rockchip_clk_register_branches: failed to register clock sdmmc_drv: -22 [ 0.000000] rockchip_clk_register_branches: failed to register clock sdmmc_sample: -17 [ 0.000000] rockchip_clk_register_branches: failed to register clock sdio0_drv: -17 [ 0.000000] rockchip_clk_register_branches: failed to register clock sdio0_sample: -17 [ 0.000000] rockchip_clk_register_branches: failed to register clock sdio1_drv: -17 [ 0.000000] rockchip_clk_register_branches: failed to register clock sdio1_sample: -17 [ 0.000000] rockchip_clk_register_branches: failed to register clock emmc_drv: -17 [ 0.000000] rockchip_clk_register_branches: failed to register clock emmc_sample: -17
エラーメッセージで検索しても、特にめぼしい報告やパッチに引っかかりません。うーん。困りましたね。
仕方ないので、更新履歴を git bisect すると 2/13 から 2/14 の間にクロックドライバが変更されたことが原因だとわかりました。
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index dc8bdfbd6a0c..ed1797857bae 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3457,7 +3457,12 @@ static int __clk_core_init(struct clk_core *core)
* Since a phase is by definition relative to its parent, just
* query the current clock phase, or just assume it's in phase.
*/
- clk_core_get_phase(core);
+ ret = clk_core_get_phase(core);
+ if (ret < 0) {
+ pr_warn("%s: Failed to get phase for clk '%s'\n", __func__,
+ core->name);
+ goto out;
+ }
/*
* Set clk's duty cycle.
しかしこの変更は真っ当に見えます。今までエラーを無視していたところをエラーチェックするようにしているだけだからです。
どの辺りでエラーが出るか調べるため printk を適当に入れたりしながら追ってみると、下記の場所で躓いていました。
// drivers/clk/clk.c
static int __clk_core_init(struct clk_core *core)
{
...
/*
* Set clk's phase by clk_core_get_phase() caching the phase.
* Since a phase is by definition relative to its parent, just
* query the current clock phase, or just assume it's in phase.
*/
phase = clk_core_get_phase(core); //★★変更が影響している場所
if (phase < 0) {
ret = phase;
pr_warn("%s: Failed to get phase for clk '%s'\n", __func__,
core->name);
//goto out;
}
// drivers/clk/clk.c
static int clk_core_get_phase(struct clk_core *core)
{
int ret;
lockdep_assert_held(&prepare_lock);
if (!core->ops->get_phase)
return 0;
/* Always try to update cached phase if possible */
ret = core->ops->get_phase(core->hw); //★★ここでエラーが発生していた
if (ret >= 0)
core->phase = ret;
return ret;
}
独自の get_phase を持っているドライバがエラーを返すと、clk_core_get_phase() もエラーを返し、先程のエラーメッセージが表示されるみたいです。しかし、この処理自体におかしな箇所はないように思います。真っ当です。
おそらく実装がおかしいのは Rockchip の MMC ドライバのクロック周りの方でしょう。エラーメッセージに出ている sdmmc_drv を頼りにコードを追います。
// drivers/clk/rockchip/clk-rk3228.c
PNAME(mux_mmc_src_p) = { "cpll", "gpll", "xin24m", "usb480m" };
...
COMPOSITE(SCLK_SDMMC, "sclk_sdmmc", mux_mmc_src_p, 0,
RK2928_CLKSEL_CON(11), 8, 2, MFLAGS, 0, 8, DFLAGS,
RK2928_CLKGATE_CON(2), 11, GFLAGS),
...
//★★sdmmc_drv はこの部分由来です
MMC(SCLK_SDMMC_DRV, "sdmmc_drv", "sclk_sdmmc", RK3228_SDMMC_CON0, 1),
// drivers/clk/rockchip/clk.h
#define MMC(_id, cname, pname, offset, shift) \
{ \
.id = _id, \
.branch_type = branch_mmc, \ //★★この値がカギかな?
.name = cname, \
.parent_names = (const char *[]){ pname }, \
.num_parents = 1, \
.muxdiv_offset = offset, \
.div_shift = shift, \
}
// drivers/clk/rockchip/clk-rk3228.c
static void __init rk3228_clk_init(struct device_node *np)
{
...
rockchip_clk_register_branches(ctx, rk3228_clk_branches, //★★ここで branch_type を見ている箇所がある
ARRAY_SIZE(rk3228_clk_branches));
...
}
//★★注: rk3228_clk_init は RK3228 のクロックコア初期化関数
// デバイスツリー内の compatible = "rockchip,rk3228-cru" を持つノードに応じて呼ばれる
CLK_OF_DECLARE(rk3228_cru, "rockchip,rk3228-cru", rk3228_clk_init);
// drivers/clk/rockchip/clk.c
void __init rockchip_clk_register_branches(
struct rockchip_clk_provider *ctx,
struct rockchip_clk_branch *list,
unsigned int nr_clk)
{
...
for (idx = 0; idx < nr_clk; idx++, list++) {
flags = list->flags;
/* catch simple muxes */
switch (list->branch_type) {
...
case branch_mmc: //★★branch_type == branch_mmc だったら
clk = rockchip_clk_register_mmc( //★★クロックの登録をしている
list->name,
list->parent_names, list->num_parents,
ctx->reg_base + list->muxdiv_offset,
list->div_shift
);
break;
...
// drivers/clk/rockchip/clk-mmc-phase.c
struct clk *rockchip_clk_register_mmc(const char *name,
const char *const *parent_names, u8 num_parents,
void __iomem *reg, int shift)
{
...
init.name = name;
init.flags = 0;
init.num_parents = num_parents;
init.parent_names = parent_names;
init.ops = &rockchip_mmc_clk_ops; //★★クロックの操作関数を登録している
...
// drivers/clk/rockchip/clk-mmc-phase.c
static const struct clk_ops rockchip_mmc_clk_ops = {
.recalc_rate = rockchip_mmc_recalc,
.get_phase = rockchip_mmc_get_phase, //★★get_phase はこの関数
.set_phase = rockchip_mmc_set_phase,
};
// drivers/clk/rockchip/clk-mmc-phase.c
static int rockchip_mmc_get_phase(struct clk_hw *hw)
{
struct rockchip_mmc_clock *mmc_clock = to_mmc_clock(hw);
unsigned long rate = clk_hw_get_rate(hw);
u32 raw_value;
u16 degrees;
u32 delay_num = 0;
/* See the comment for rockchip_mmc_set_phase below */
if (!rate)
return -EINVAL; //★★エラーを返している
...
原因らしき箇所が見つかりました。クロック周波数(rate)が設定されていなくても、エラーを返す必要はなく、phase の初期値 0 を返せば良いはずですから、return -EINVAL を return 0 にすれば良さそうです。
変更すると無事 linux-next が起動できるようになりました。良かった良かった。
こんなバグを 2週間以上放置するなんて linux らしくないなと思って、パッチを送ろうとしましたが……、なんだかとっても嫌な予感がしたので、rochchip_mmc_get_phase で LKML を検索してみました。
検索してびっくり、なんと、全く同じ指摘をしているパッチが先週 LKML に送られています(LKML へのリンク)。しかも既に clk-next に取り込まれているじゃないですか。ですが linux-next への反映はまだのようです。
明日まで待っていれば clk-next が linux-next に取り込まれるので、何もしなくても解決していたんです。パッチ投稿が 3/4 なので、今回は本当に気づくタイミングが悪かったです。
Author: Jerome Brunet < >
Date: Tue Mar 3 20:29:56 2020 +0100
clk: rockchip: fix mmc get phase
If the mmc clock has no rate, it can be assumed to be constant.
In such case, there is no measurable phase shift. Just return 0
in this case instead of returning an error.
Fixes: 2760878662a2 ("clk: Bail out when calculating phase fails during clk
registration")
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
diff --git a/drivers/clk/rockchip/clk-mmc-phase.c b/drivers/clk/rockchip/clk-mmc-phase.c
index 4abe7ff31f53..975454a3dd72 100644
--- a/drivers/clk/rockchip/clk-mmc-phase.c
+++ b/drivers/clk/rockchip/clk-mmc-phase.c
@@ -51,9 +51,9 @@ static int rockchip_mmc_get_phase(struct clk_hw *hw)
u16 degrees;
u32 delay_num = 0;
- /* See the comment for rockchip_mmc_set_phase below */
+ /* Constant signal, no measurable phase shift */
if (!rate)
- return -EINVAL;
+ return 0;
raw_value = readl(mmc_clock->reg) >> (mmc_clock->shift);
前にも、原因を突き止めたら、解決済みだったというパターン(2018年 12月 4日の日記、2019年 9月 18日の日記)がありました。
またこの「鶏と卵のパターン」にやられました。ついてない。
コードに特攻する前に、ちゃんと探せば?って思われるかもしれませんが、困ったことにエラーメッセージで検索してもパッチに辿り着けないんです。調べに調べて原因と対策がわかった後に、はぁ?もうパッチあるじゃん!?と気づくから、徒労感が激しい……。
37歳になりました。おめでとう俺、ありがとう俺。30代も残りわずかです。
何歳になろうが、本人は特に何も変わってませんが、周りから見ると確実にオジサンです。若者へ説教と昔の自慢話だけは絶対しないように気をつけます。
今に始まったことじゃないんですが、いつも何歳だか良くわからなくなります。もちろん (現在の西暦) - (生まれた西暦) で、1月1日〜3月9日は -1 すれば良いのはわかってますが、ぱっと答えられません。なぜなのか……。
GCC はアーキテクチャごとに設定ファイルがあって gcc/config/(アーキテクチャ名)/ という名前のディレクトリ下に配置されています。
その中に machine mode を設定するファイルがあります。例えば RISC-V なら gcc/config/riscv/riscv-modes.def ですし、AArch64 なら gcc/config/aarch64/aarch64-modes.def です。machine mode とは何かはちょっと横に置いて、このファイルの探し方が割と不思議な作りだったので紹介します。
GCC のビルドプロセスは非常にややこしいです。xxxx-modes.def は GCC のコードで直接使われず、前処理で使われます。GCC のビルドディレクトリを (build_dir) と書くとすると、
こんな仕組みになっています。起点となる genmodes.c から見ます。
// gcc/genmodes.c
static void
create_modes (void)
{
#include "machmode.def" //★★これに全てのモードが定義されている
// gcc/machmode.def
/* Allow the target to specify additional modes of various kinds. */
#if HAVE_EXTRA_MODES
# include EXTRA_MODES_FILE //★★追加のファイルがあれば include
#endif
// gcc/genmodes.c
#ifdef EXTRA_MODES_FILE
# define HAVE_EXTRA_MODES 1
#else
# define HAVE_EXTRA_MODES 0
# define EXTRA_MODES_FILE ""
#endif
EXTRA_MODES_FILE というマクロにファイル名が定義されていれば、そのファイルも include する仕組みになっています。C 言語を見慣れている人もかなり面食らう書き方ですが、GCC は「*.def ファイルを include する」という技を乱発します。メチャクチャすぎる。
EXTRA_MODES_FILE をマクロを定義するのは config.gcc と configure です。
# gcc/config.gcc
extra_modes=
if test -f ${srcdir}/config/${cpu_type}/${cpu_type}-modes.def
then
extra_modes=${cpu_type}/${cpu_type}-modes.def # ★★aarch64-modes.def のような名前のファイルが存在すればそのファイルを使う
fi
# gcc/configure
# Collect target-machine-specific information.
. ${srcdir}/config.gcc || exit 1 # ★★config.gcc の設定を取り込む
...
# Look for a file containing extra machine modes.
if test -n "$extra_modes" && test -f $srcdir/config/$extra_modes; then
extra_modes_file='$(srcdir)'/config/${extra_modes} # ★★extra_modes は config.gcc で定義したものが導入される
cat >>confdefs.h <<_ACEOF
#define EXTRA_MODES_FILE "config/$extra_modes" # ★★config/aarch64/aarch64-modes.def のような値になる
_ACEOF
fi
やっとたどり着きました。GCC ってちょっとしたことでも、ものすごく複雑にできていて、読むのが辛いというか、読んでも意味不明なことが多いです。うーん、辛い。
引っ越してから 1年もの間、車検証の住所変更をせずにほったらかしていました(本当は良くない)が、重い腰を上げ、大阪ナンバーにお別れを告げて、品川ナンバーになりました。
手続きに興味があったので、あえてディーラーにお任せせず自分でやってみました。面白かったですが相当面倒くさいです。もう自分でやることはないでしょうね。
今回は「変更登録」という手続きをしました。車検証の住所変更&ナンバープレートの変更です。他県から東京都に引っ越した人が該当します。手続きはざっくりいうと、
どうがんばって圧縮しても、平日を 2回消費します。普通は警察、警察、陸運局、の 3回消費すると思います。警察も陸運局も平日しか受け付けしていないので、勤め人にはなかなか辛いです。
興味のある人は居なさそうですが、メモ代わりに書いておきます。まずは車庫証明用の書類が必要です。
ここまでの書類は全部の警視庁のサイト(保管場所証明申請手続 - 警視庁)からゲットできます。
ナンバーの封印を付けてもらったら、そのまま車で運輸局からおさらばです。
やってみた感想は「RPG のクエストみたい」です。書類と書類を交換していくと、最後に車検証とナンバープレートが貰えます、みたいな感じですね。車のナンバー(と自動車税)管理の一環が垣間見えて、なかなか面白い社会科見学でした。
個人的にはナンバープレートの封印を破壊するのは、普段やらない体験で「え?自分で壊すの??」と緊張しました(関東運輸局だけセルフで、他地域ではやらないみたいです)。私の車は粗雑に扱っているせいなのか、フロント側のナンバーのネジが錆びて固着しており、あやうくネジをなめそうでした。次はもう外せないかもしれない。
昨今のコロナ騒ぎのせいか、いずれの窓口もガラッガラに空いていて快適でした。混んでいたら地獄だったと思います。
前回(2020年 3月 6日の日記参照)はレジスタ制約(register_constraints)を追加しました。これだけでは何もできませんので、今回はベクトルレジスタの定義を追加してみます。長そうなので分割して書きます。
RISC-V には汎用レジスタ(GP_REGS)と浮動小数点レジスタ(FP_REGS)が既に定義されているため、それらを参考にします。
変更するファイルは gcc/config/riscv/riscv.c, riscv.h です。FP_REG くらいで検索すると、下記の関数、マクロに名前が見当たりますので、真似して追加します。(詳細は パッチファイルもご覧ください、内容の正しさは全く保証できませんけど)
// gcc/config/riscv/riscv.c
riscv_regno_to_class[FIRST_PSEUDO_REGISTER] //32個レジスタを足す
riscv_hard_regno_nregs //どのマシンモードでもレジスタを 1つだけ使う、よくわからん、また今度調べる
riscv_hard_regno_mode_ok //どのマシンモードでも許可する、よくわからん、また今度調べる
riscv_class_max_nregs //どのクラスでもレジスタを 1つだけ使う、よくわからん、また今度調べる
// gcc/config/riscv/riscv.h
FIRST_PSEUDO_REGISTER //32個分ずれてもらう
FIXED_REGISTERS //32個足す、今回は 0 にした、固定された役目(スタックポインタなど)はない
CALL_USED_REGISTERS //32個足す、今回は 0 にした(関数呼び出しにより内容を破壊されない、s0 - s11 と同じ扱い)
enum reg_class
#define REG_CLASS_NAMES //新たなレジスタクラスを足す
#define REG_CLASS_CONTENTS //後述する
#define REG_ALLOC_ORDER //レジスタの割当順、レジスタ番号で指定する
#define REGISTER_NAMES //レジスタの名前
#define ADDITIONAL_REGISTER_NAMES
初歩の初歩的な変更の割に必要な変更点はかなり多いです。どの変更が何に効くか完全にわかっていないので、合っているかわかりませんし、説明し難い変更もあります。後日、要調査ですね。
変更した中の riscv_regno_to_class をみると FIRST_PSEUDO_REGISTER というマクロが出てきます。GCC はレジスタを 2種類使い分けていて、レジスタ番号で区別できます。
正式な名前がわからない(※)ので、名付けは適当です。GCC は RTL のフェーズで命令の引数にレジスタを割り当てます。その際、いきなりメモリや物理レジスタを割り当てるのではなく、まず疑似レジスタを割り当てます。
疑似レジスタには数の制限がないので、最初の方の最適化パスで必要なだけ割り当てます。その後の最適化パスで物理レジスタや、メモリにうまく割り当てを考える二段構成になっています。
今回は 32個の物理レジスタを足そうとしているので、FIRST_PSEUDO_REGISTER にも 32個分だけズレてもらう必要があります。
今回の変更の要は REG_CLASS_CONTENTS です。このマクロの効き目についてはまた今度。
(※)GCC のヘンテコなマクロの意味を調べる際、GCC Internals(HTML 版へのリンク)が大変参考になるのですが、この文書は用語の説明がイマイチ甘くて、正式な用語がわかりません。いつも困ります……。
レジスタ追加の変更の要は REG_CLASS_CONTENTS です。このマクロは 32ビット整数の配列で、各レジスタ番号がどのレジスタの仲間(enum reg_class)に属するかを指定するテーブルです。こんな風に変更します。
#define REG_CLASS_CONTENTS \
{ \
- { 0x00000000, 0x00000000, 0x00000000 }, /* NO_REGS */ \
- { 0xf003fcc0, 0x00000000, 0x00000000 }, /* SIBCALL_REGS */ \
- { 0xffffffc0, 0x00000000, 0x00000000 }, /* JALR_REGS */ \
- { 0xffffffff, 0x00000000, 0x00000000 }, /* GR_REGS */ \
- { 0x00000000, 0xffffffff, 0x00000000 }, /* FP_REGS */ \
- { 0x00000000, 0x00000000, 0x00000003 }, /* FRAME_REGS */ \
- { 0xffffffff, 0xffffffff, 0x00000003 } /* ALL_REGS */ \
+ { 0x00000000, 0x00000000, 0x00000000, 0x00000000 }, /* NO_REGS */ \
+ { 0xf003fcc0, 0x00000000, 0x00000000, 0x00000000 }, /* SIBCALL_REGS */ \
+ { 0xffffffc0, 0x00000000, 0x00000000, 0x00000000 }, /* JALR_REGS */ \
+ { 0xffffffff, 0x00000000, 0x00000000, 0x00000000 }, /* GR_REGS */ \
+ { 0x00000000, 0xffffffff, 0x00000000, 0x00000000 }, /* FP_REGS */ \
+ { 0x00000000, 0x00000000, 0xffffffff, 0x00000000 }, /* VP_REGS */ \
+ { 0x00000000, 0x00000000, 0x00000000, 0x00000003 }, /* FRAME_REGS */ \
+ { 0xffffffff, 0xffffffff, 0xffffffff, 0x00000003 } /* ALL_REGS */ \
}
↑ここの 3列目を足した
行方向は、ビットフィールドになっており非常にわかりにくいです。0要素目の 0ビット目、0要素目の 1ビット目、…という順に見ます。整数内では右から左(右が上位ビット)、要素間では左から右(左が 0要素目)に見ます。
列方向は enum reg_class の整数値と一致しますのでさほど難しくはないでしょう。
行と列の意味 →→ 行方向、レジスタ番号(0 〜 FIRST_PSEUDO_REGISTER - 1 まで) ↓ ↓ 列方向、enum reg_class を整数に直したもの 行方向の見方 例えば 3行目(GR_REGS)がこうなっていたとすると、 { 0x0000000f, 0x0000000c, }, - 0要素目(レジスタ番号 0 〜 31 のクラス): 0x0000000f - 0, 1, 2, 3ビット目が 1 = レジスタ番号 0 〜 3 は GR_REGS - 他のレジスタについては言及しない - 1要素目(レジスタ番号 32 〜 63 のクラス): 0x0000000c - 2, 3ビット目が 1 = レジスタ番号 34 〜 35 は GR_REGS - 他のレジスタについては言及しない
ALL_REGS は全レジスタに 1 をセットしますので、ビットフィールドのルールがわかりやすいと思います。今回はレジスタが 98本なので、3要素(32 * 3 = 96)+ 最後の要素は 2ビット分だけ 1 にセットしています。
今回は VR_REGS という新たなレジスタクラスを足したいので、行が一つ増えます。レジスタの総数も増えるので、列方向も増えます。ちょうど良いことに新規に追加するレジスタは 32本なので、整数 1要素分を増やすだけです。
このマクロは直接使用されるわけではなく、別の配列にコピーされます。
// gcc/reginfo.c
static const unsigned int_reg_class_contents[N_REG_CLASSES][N_REG_INTS]
= REG_CLASS_CONTENTS;
...
/* Function called only once per target_globals to initialize the
target_hard_regs structure. Once this is done, various switches
may override. */
void
init_reg_sets (void)
{
int i, j;
/* First copy the register information from the initial int form into
the regsets. */
for (i = 0; i < N_REG_CLASSES; i++)
{
CLEAR_HARD_REG_SET (reg_class_contents[i]);
/* Note that we hard-code 32 here, not HOST_BITS_PER_INT. */
for (j = 0; j < FIRST_PSEUDO_REGISTER; j++)
if (int_reg_class_contents[i][j / 32] //★★ここで参照している
& ((unsigned) 1 << (j % 32)))
SET_HARD_REG_BIT (reg_class_contents[i], j);
}
// gcc/reginfo.c
struct target_hard_regs default_target_hard_regs;
// gcc/hard-reg-set.h
#if SWITCHABLE_TARGET //★★x86, ARM, MIPS などは SWITCHABLE_TARGET = 1, RISC-V は 0 のようだ
extern struct target_hard_regs *this_target_hard_regs;
#else
#define this_target_hard_regs (&default_target_hard_regs)
#endif
#define reg_class_contents \r (this_target_hard_regs->x_reg_class_contents)
難しそうに見えてやっていることは int_reg_class_contents から default_target_hard_regs->x_reg_class_contents へビットを移し替えているだけです。違いは int_reg_class_contents が必ず 32ビット幅であるのに対し、x_reg_class_contents はアーキテクチャ最速の整数幅(x86_64 なら 64bit になるでしょう)である点です。
個人的には可読性を殺してまでやる意味あるの……?と疑問ですが、きっと GCC 内で頻繁に呼ばれ速度的に重要なポイントだったのでしょう。
インラインアセンブラで "v" constraints を指定すると、何も実装していない場合は impossible constraint in 'asm' と怒られました。レジスタの constraints だけ足すと inconsistent operand constraints in an asm と怒られるはずです。エラーをチェックしている箇所は、
static bool
curr_insn_transform (bool check_only_p)
{
...
if (process_alt_operands (reused_alternative_num)) //★★これが成立して alt_p = true が期待値だが
alt_p = true;
...
if (! alt_p && ! sec_mem_p)
{
/* No alternative works with reloads?? */
if (INSN_CODE (curr_insn) >= 0)
fatal_insn ("unable to generate reloads for:", curr_insn);
error_for_asm (curr_insn,
"inconsistent operand constraints in an %<asm%>"); //★★ここに到達しエラーが出る
lra_asm_error_p = true;
/* Avoid further trouble with this insn. Don't generate use
pattern here as we could use the insn SP offset. */
lra_set_insn_deleted (curr_insn);
return true;
}
...
この curr_insn_transform() 関数はやたら長くて(700行)訳のわからない構造です。うまく行く場合(r などを渡したとき)を観察すると、alt_p が true になるのが期待値と思われます。幸いなことに alt_p の設定は一箇所だけ、条件も process_alt_operands() 関数だけです。
そう思って process_alt_operands() 関数を見ると、これがまたもの凄い実装で、目を覆いたくなります(1200行!!)。GCC 見ていると、クソコードには事欠かないです。これはひどい。
コードの一部を抜粋しても全く意味不明で、そもそもこの関数自体がかなりゴチャゴチャで意味不明です。全て追うのは不可能です。なので "r" がどの辺りを通るかをもって、当たりを付けました。下記のところが分岐点になっているようです。
static bool
process_alt_operands (int only_alternative)
{
...
do
{
//★★p は "=&v" が入っていて、c に先頭から一文字ずつ取って解析している
switch ((c = *p, len = CONSTRAINT_LEN (c, p)), c)
{
case '\0':
len = 0;
break;
...
default:
cn = lookup_constraint (p); //★★ 'v' に対しては、CONSTRAINT_v が返る
switch (get_constraint_type (cn))
{
case CT_REGISTER:
cl = reg_class_for_constraint (cn); //★★CONSTRAINT_v に対しては VP_REGS が返る
if (cl != NO_REGS)
goto reg; //★★このジャンプで飛ぶ
break;
...
reg:
if (mode == BLKmode)
break;
this_alternative = reg_class_subunion[this_alternative][cl];
this_alternative_set |= reg_class_contents[cl]; //★★どこかでみた reg_class_contents が登場
if (costly_p)
{
this_costly_alternative
= reg_class_subunion[this_costly_alternative][cl];
this_costly_alternative_set |= reg_class_contents[cl];
}
winreg = true;
if (REG_P (op))
{
if (hard_regno[nop] >= 0
&& in_hard_reg_set_p (this_alternative_set,
mode, hard_regno[nop])) //★★これが成立しない
win = true; //★★少なくとも win = true にならないと関数が失敗を返す(条件は他にもあるが)
else if (hard_regno[nop] < 0
&& in_class_p (op, this_alternative, NULL))
win = true;
}
break;
}
...
}
while ((p += len), c); //★★基本は次の文字に行くが、スキップすることもある模様
どこかでみたアイツです。このエラーは reg_class_contents を見に行った結末に起きているようです。
REG_CLASS_CONTENTS を正しく設定すると、下記のコードがコンパイルできるはずです。雰囲気を出すため RISC-V のベクトル命令を書いていますが、ぶっちゃけコンパイラは命令を全く見ないので、実は abcd でも何でも通ります。コンパイルのみ(*.s を出力)であればアセンブラすら要りません(※)。
// a.c
void _start()
{
int b[100];
int v;
__asm__ volatile ("vlw.v %0, %1\n"
: "=&v"(v) : "A"(b[10]));
}
ビルドして、逆アセンブルしてみます。
$ riscv32-unknown-elf-gcc -Wall -g -march=rv32gcv -mabi=ilp32f -nostdlib -O2 a.c $ riscv32-unknown-elf-objdump -drS a.out a.out: file format elf32-littleriscv Disassembly of section .text: 00010054 <_start>: void _start() { 10054: 7165 addi sp,sp,-400 int b[100]; int v; __asm__ volatile ("vlw.v %0, %1\n" 10056: 103c addi a5,sp,40 10058: 1207e007 vlw.v v0,(a5) : "=&v"(v) : "A"(b[10])); } 1005c: 6159 addi sp,sp,400 1005e: 8082 ret
それらしきベクトルレジスタ(v0)が出力されているようです。めでたし、めでたし。と言いたいところですが、実は全然ダメです。
まだまだ改善の余地があります。これも今後、調べていこうと思います。
(※)もしアセンブルまで実行したければ、RISC-V の GitHub にある binutils を使ってください(GitHub へのリンク)。ビルド方法は Upstream のコードとほぼ同じ(2019年 4月 19日の日記参照)です。唯一の違いは configure 時に --with-system-readline を付けないと、readline がないと言われてエラーになる点です。
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2021.
Powered by PHP 5.2.17.
using GD bundled (2.0.34 compatible)(png support.)