link もっと前
   2020年 5月 23日 -
      2020年 5月 14日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

link 編集する

GCC を調べる - その 11-2 - オプション O0 のエラーを引き起こす RTL

前回(2020年 5月 22日の日記参照)の続きです。エラーの原因となる代入操作 RTL はどこから出てきているのでしょう。RTL を遡っていくと expand から出力されていることがわかります。expand は RTL の最初のパスで、GIMPLE から RTL に変換するためのパス(パス番号 236)です。最初から間違っているということですね。

236r.expand
;;★★asm 文に相当する箇所

(insn 74 7 10 2 (set (reg:V64SI 109 [ v1 ])
        (asm_operands/v:V64SI ("vlw.v %0, %1
") ("=&v") 0 [
                (mem/c:SI (plus:SI (reg/f:SI 99 virtual-stack-vars)
                        (const_int -360 [0xfffffffffffffe98])) [1 b+40 S4 A64])
            ]
             [
                (asm_input:SI ("A") b.c:7)
            ]
             [] b.c:7)) "b.c":7:2 -1
     (nil))

;;★★自動的に出力される代入操作らしき RTL

(insn 10 74 11 2 (set (mem/c:SI (reg/f:SI 108) [1 v1+0 S4 A2048])
        (subreg:SI (reg:V64SI 109 [ v1 ]) 0)) "b.c":7:2 -1
     (nil))
(insn 11 10 12 2 (set (mem/c:SI (plus:SI (reg/f:SI 108)
                (const_int 4 [0x4])) [1 v1+4 S4 A32])
        (subreg:SI (reg:V64SI 109 [ v1 ]) 4)) "b.c":7:2 -1
     (nil))
(insn 12 11 13 2 (set (mem/c:SI (plus:SI (reg/f:SI 108)
                (const_int 8 [0x8])) [1 v1+8 S4 A64])
        (subreg:SI (reg:V64SI 109 [ v1 ]) 8)) "b.c":7:2 -1
     (nil))

...

ベクトル型 V64SI のまま処理してほしいのに、4バイトごとに分割されて代入処理されています。この分割はどこで行われているか調べます。GCC は insn RTL を出力するときは必ず emit_insn() という関数で出力することを利用します。

  • 代入操作の先頭の insn は UID 10 です。ダンプファイルで確認するなら insn の隣にある数字(insn '10' ←これ 74 11 2 …)が UID です。
  • emit_insn() を書き換えて、INSN_UID(x) == 10 のときに適当に作った関数 hoge() に飛ばすようにします。
  • gdb で関数 hoge() にブレークを掛けると、ちょうど目当ての RTL を出力した瞬間に実行が止まります。

ブレークで実行が止まったら、バックトレースを取れば呼び出しまでの経路がわかります。

代入操作の先頭 insn を出力したときのバックトレース
(gdb) bt
#0  hoge () at ./gcc/gcc/emit-rtl.c:5103
#1  0x000000000097ebf9 in emit_insn (x=0x7ffff7aaa400)
    at ./gcc/gcc/emit-rtl.c:5118
#2  0x00000000009ff017 in emit_move_insn_1 (x=0x7ffff7bada80, y=0x7ffff7bada98)
    at ./gcc/gcc/expr.c:3754
#3  0x00000000009ffa28 in emit_move_insn (x=0x7ffff7bada80, y=0x7ffff7bada98)
    at ./gcc/gcc/expr.c:3858

★★↓いかにも分割していそうな、怪しい名前

#4  0x00000000009fee38 in emit_move_multi_word (mode=E_V64SImode, x=0x7ffff7bada68, y=0x7ffff7bada50)
    at ./gcc/gcc/expr.c:3720
#5  0x00000000009ff505 in emit_move_insn_1 (x=0x7ffff7bada68, y=0x7ffff7bada50)
    at ./gcc/gcc/expr.c:3791
#6  0x00000000009ffa28 in emit_move_insn (x=0x7ffff7bada68, y=0x7ffff7bada50)
    at ./gcc/gcc/expr.c:3858
#7  0x0000000000a0cc8d in store_expr (exp=0x7ffff7ffb480, target=0x7ffff7bada68, call_param_p=0,
    nontemporal=false, reverse=false)
    at ./gcc/gcc/expr.c:5932
#8  0x0000000000a09064 in expand_assignment (to=0x7ffff7aa7750, from=0x7ffff7ffb480, nontemporal=false)
    at ./gcc/gcc/expr.c:5517
#9  0x000000000076c911 in expand_asm_stmt (stmt=0x7ffff7b8f4e0)
    at ./gcc/gcc/cfgexpand.c:3198
#10 0x000000000076f89a in expand_gimple_stmt_1 (stmt=0x7ffff7b8f4e0)
    at ./gcc/gcc/cfgexpand.c:3685
#11 0x00000000007705f0 in expand_gimple_stmt (stmt=0x7ffff7b8f4e0)
    at ./gcc/gcc/cfgexpand.c:3853
#12 0x000000000077e7f1 in expand_gimple_basic_block (bb=0x7ffff7aba2d8, disable_tail_calls=false)
    at ./gcc/gcc/cfgexpand.c:5893
#13 0x0000000000781a25 in (anonymous namespace)::pass_expand::execute (this=0x449bbf0, fun=0x7ffff7baa000)

バックトレースの中に怪しい名前の関数 emit_move_multi_word() があります。いかにも複数の insn を出力しそうな名前です。emit_move_multi_word までを追うと、下記のような経路を辿っています。

代入が分割されるところ

// gcc/cfgexpand.c

static void
expand_asm_stmt (gasm *stmt)
{

...

  for (i = 0; i < noutputs; ++i)
    {
      tree val = output_tvec[i];
      tree type = TREE_TYPE (val);
      bool is_inout, allows_reg, allows_mem, ok;
      rtx op;

...

      if ((TREE_CODE (val) == INDIRECT_REF && allows_mem)
	  || (DECL_P (val)
	      && (allows_mem || REG_P (DECL_RTL (val)))
	      && ! (REG_P (DECL_RTL (val))
		    && GET_MODE (DECL_RTL (val)) != TYPE_MODE (type)))
	  || ! allows_reg
	  || is_inout
	  || TREE_ADDRESSABLE (type))
	{

...

	}
      else
	{
	  op = assign_temp (type, 0, 1);
	  op = validize_mem (op);
	  if (!MEM_P (op) && TREE_CODE (val) == SSA_NAME)
	    set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (val), op);

	  generating_concat_p = old_generating_concat_p;

	  push_to_sequence2 (after_rtl_seq, after_rtl_end);
	  expand_assignment (val, make_tree (type, op), false);  //★★これ
	  after_rtl_seq = get_insns ();
	  after_rtl_end = get_last_insn ();
	  end_sequence ();
	}


// gcc/expr.c

/* Expand an assignment that stores the value of FROM into TO.  If NONTEMPORAL
   is true, try generating a nontemporal store.  */

void
expand_assignment (tree to, tree from, bool nontemporal)
{

...

  /* Compute FROM and store the value in the rtx we got.  */

  push_temp_slots ();
  result = store_expr (from, to_rtx, 0, nontemporal, false);  //★★これ
  preserve_temp_slots (result);
  pop_temp_slots ();
  return;
}

rtx_insn *
emit_move_insn (rtx x, rtx y)
{
  machine_mode mode = GET_MODE (x);
  rtx y_cst = NULL_RTX;
  rtx_insn *last_insn;
  rtx set;

...

  last_insn = emit_move_insn_1 (x, y);  //★★これ

  if (y_cst && REG_P (x)
      && (set = single_set (last_insn)) != NULL_RTX
      && SET_DEST (set) == x
      && ! rtx_equal_p (y_cst, SET_SRC (set)))
    set_unique_reg_note (last_insn, REG_EQUAL, copy_rtx (y_cst));

  return last_insn;
}

rtx_insn *
emit_move_insn_1 (rtx x, rtx y)
{
  machine_mode mode = GET_MODE (x);
  enum insn_code code;

  gcc_assert ((unsigned int) mode < (unsigned int) MAX_MACHINE_MODE);

  code = optab_handler (mov_optab, mode);
  if (code != CODE_FOR_nothing)    //★★CODE_FOR_nothing になるのが怪しい
    return emit_insn (GEN_FCN (code) (x, y));    //★★こっちに行けばいいのだろうか??

  /* Expand complex moves by moving real part and imag part.  */
  if (COMPLEX_MODE_P (mode))
    return emit_move_complex (mode, x, y);    //★★もしくはこっち??

...

  return emit_move_multi_word (mode, x, y);    //★★この関数が呼ばれ、分割される
}

せっかく辿っておいてこんなこというのは若干気が引けますが、なぜこの経路を辿るのか?コードを見ても全くわかりません。特に expand_asm_stmt() から emit_move_insn() までは、各関数が非常に長く、訳のわからない if 文が山ほどあります。GCC ってどうして動いてるんでしょうね?大丈夫?これ??

GCC のコードの酷さはさておき、emit_move_multi_word() と他の関数への分岐点になっている、emit_move_insn_1() が怪しそうです。次回以降、この関数を中心に調べます。

[編集者: すずき]
[更新: 2020年 5月 25日 02:55]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

GCC を調べる - その 11-1 - オプション O0 のエラー調査

前回(2020年 5月 16日の日記2020年 5月 17日の日記参照)の取り組みでインラインアセンブラでベクトル型を指定できるようになりましたが、下記の問題が残っていました。

  • 最適化オプションを O0 にするとコンパイラが internal error を出す

いよいよコンパイラが Internal compile error を出す問題に取り組みます。ベクトル型を使ったインラインアセンブラを O0 でコンパイルすると、下記のようなエラーメッセージが出ます。

O0 のときのエラーメッセージ
b.c: In function '_start':
b.c:25:1: internal compiler error: maximum number of generated reload insns per insn achieved (90)
   25 | }
      | ^

このエラーが出るパスは reload です。問題のある箇所に当たりをつけるため、O0 の reload と、1つ前のパス ira の RTL を比べます。

O0 の 281r.ira

;;★★asm 文

(insn 74 7 10 2 (set (reg:V64SI 109 [ v1 ])
        (asm_operands/v:V64SI ("vlw.v %0, %1") ("=&v") 0 [
                (mem/c:SI (plus:SI (reg/f:SI 97 frame)
                        (const_int -360 [0xfffffffffffffe98])) [1 b+40 S4 A64])
            ]
             [
                (asm_input:SI ("A") b.c:7)
            ]
             [] b.c:7)) "b.c":7:2 -1
     (nil))

;;★★スタックへの退避かな?

(insn 10 74 11 2 (set (mem/c:SI (reg/f:SI 108) [1 v1+0 S4 A2048])*movsi_internal
     (nil))
(insn 11 10 12 2 (set (mem/c:SI (plus:SI (reg/f:SI 108)
                (const_int 4 [0x4])) [1 v1+4 S4 A32])*movsi_internal
     (nil))

...
O0 の 282r.reload

;;★★asm 文

(insn 74 147 146 2 (set (reg:V64SI 112 [orig:109 v1 ] [109])
        (asm_operands/v:V64SI ("vlw.v %0, %1") ("=&v") 0 [
                (mem/c:SI (reg:SI 113) [1 b+40 S4 A64])
            ]
             [
                (asm_input:SI ("A") b.c:7)
            ]
             [] b.c:7)) "b.c":7:2 -1
     (nil))
(insn 146 74 236 2 (clobber (reg:V64SI 109 [ v1 ])) "b.c":7:2 -1
     (nil))

;;★★変な insn が大量に増えている(ここから)

(insn 236 146 235 2 (set (reg:SI 202)*movsi_internal
     (nil))
(insn 235 236 234 2 (set (reg:SI 201)*movsi_internal
     (nil))

...

(insn 144 143 145 2 (set (subreg:SI (reg:V64SI 109 [ v1 ]) 248)*movsi_internal
     (nil))
(insn 145 144 10 2 (set (subreg:SI (reg:V64SI 109 [ v1 ]) 252)*movsi_internal
     (nil))

;;★★変な insn が大量に増えている(ここまで)

;;★★スタックへの退避かな?

(insn 10 145 11 2 (set (mem/c:SI (reg/f:SI 108) [1 v1+0 S4 A2048])*movsi_internal
     (nil))
(insn 11 10 12 2 (set (mem/c:SI (plus:SI (reg/f:SI 108)
                (const_int 4 [0x4])) [1 v1+4 S4 A32])*movsi_internal
     (nil))

...

どうやら asm 文の後に出てくる代入操作らしき RTL を処理しようとすると死んでしまうようです。次に O2 と O0 の違いを調べます。パス reload より前に実行され、なおかつ O0 と O2 双方で共通のパスは ira ですから、ira の RTL を比較します。

O2 と O0 のときの 281r.ira

;;★★O2 のとき

(insn 73 7 204 2 (set (reg:V64SI 105 [ v1 ])
        (asm_operands/v:V64SI ("vlw.v %0, %1") ("=&v") 0 [
                (mem/c:SI (plus:SI (reg/f:SI 97 frame)
                        (const_int -360 [0xfffffffffffffe98])) [1 b+40 S4 A64])
            ]
             [
                (asm_input:SI ("A") b.c:7)
            ]
             [] b.c:7)) "b.c":7:2 -1
     (expr_list:REG_UNUSED (reg:V64SI 105 [ v1 ])
        (nil)))
(debug_insn 204 73 203 2 (var_location:V64SI D#65 (clobber (const_int 0 [0]))) -1
     (nil))
(debug_insn 203 204 202 2 (var_location:SI D#64 (subreg:SI (debug_expr:V64SI D#65) 0)) -1
     (nil))
(debug_insn 202 203 201 2 (var_location:SI D#63 (subreg:SI (debug_expr:V64SI D#65) 4)) -1
     (nil))


;;★★O0 のとき

(insn 74 7 10 2 (set (reg:V64SI 109 [ v1 ])
        (asm_operands/v:V64SI ("vlw.v %0, %1") ("=&v") 0 [
                (mem/c:SI (plus:SI (reg/f:SI 97 frame)
                        (const_int -360 [0xfffffffffffffe98])) [1 b+40 S4 A64])
            ]
             [
                (asm_input:SI ("A") b.c:7)
            ]
             [] b.c:7)) "b.c":7:2 -1
     (nil))
(insn 10 74 11 2 (set (mem/c:SI (reg/f:SI 108) [1 v1+0 S4 A2048])*movsi_internal
     (nil))
(insn 11 10 12 2 (set (mem/c:SI (plus:SI (reg/f:SI 108)
                (const_int 4 [0x4])) [1 v1+4 S4 A32])*movsi_internal
     (nil))
(insn 12 11 13 2 (set (mem/c:SI (plus:SI (reg/f:SI 108)
                (const_int 8 [0x8])) [1 v1+8 S4 A64])*movsi_internal
     (nil))

結論から先に言えば O2 でも O0 でも問題のある RTL が生成されていると考えられます。RTL の所見をまとめると、

  • O2 も O0 も似たような代入操作と思しき RTL が出力されています。
  • O2 の場合は代入操作が 243r.fwprop1 で消されます。
  • O2 も O0 も fwprop1 より前の RTL はほぼ同じです。

O2 で Internal compile error が発生しないのはラッキーに過ぎなかったようです。次回は問題となる RTL がどこから来るのか調べます。

[編集者: すずき]
[更新: 2020年 5月 23日 03:38]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

さようなら SeaMonkey

かつての Mozilla のころからずっと使っていた SeaMonkey ですが、最近のサイトだと知らない子扱いされて悲しいのと、Cookie の削除がしづらくてたまらないので、ブラウザを Firefox に変えました。

SeaMonkey 今までありがとう。大変お世話になりました。

こんにちは Firefox

ブラウザに限らず、あまりアプリケーションのカスタマイズはしない方ですが、今の Windows 版 Firefox は 1点だけ嫌なところがあります。Ctrl+Tab を押したときにタブの一覧が出る挙動です。

Windows のウインドウ切り替えと似ていますが、ブラウザのタブは元から横一直線に並んでいるので、リストを出す必要はないです。隣のタブに迅速に切り替えてほしい。

調べてみると browser.ctrlTab.recentlyUsedOrder を false にすると Ctrl+Tab を押した瞬間に隣のタブに移る挙動に戻せることを知りました。とても嬉しい。これだよこれ!

[編集者: すずき]
[更新: 2020年 5月 23日 02:45]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

超えろ、新宿駅

Steam で新たなゲームを買いました。2020年 4月ローンチの STATIONflow(開発: DMM GAMES)です。その名の通り地下鉄の駅を作るゲームです。


STATIONflow ロゴ

新宿や渋谷のようなモンスター駅の作り、使いづらさに憤慨したことはありませんか?「使いづらい!俺様に任せればスマートに作ってやる」と思う方はぜひチャレンジしてください。

私もそう思ってたのですが、ゲームをやってみて「思い上がりでした、ごめんなさい、JR さん尊敬してます。」反省しました。油断するとすぐに、客を何度も上り下りさせて、べらぼうに長距離歩かせて、挙句迷子になるクソ駅が爆誕します。

良いところ、嫌なところ

(気に入ったところ)

  • 動作が非常に快適。特に起動が超速くて、ノート PC でも数秒で起動します。Transport Fever 2 は寝そうなくらい遅くて辛かったので、これは嬉しいです。

(気に入らないところ)

  • 今年のゲームの割にグラフィックスがショボい。殺人現場の再現グラフィックみたいに見えます。
  • 操作方法が変。カメラワークも変ですし、一番嫌なのがマップスクロールで、なぜかミドルドラッグです。右ドラッグが普通では?

ゲームはまだ始めたばかりなので、主に操作性の面での感想です。

ゲームシステム紹介

プレイ時間が 10時間未満で、序盤しか体験してませんが、STATIONflow のシステム紹介もしておきます。システムはそんなに難しくないです。

システム紹介: 客の動きと構内案内

マップには地下鉄の改札口と、電車の到着ホームが固定で置かれます。お客さんの行動は基本的に 3つです。

  • 改札←→改札(通過)
  • ホーム←→改札(乗降車)
  • ホーム←→ホーム(乗り換え)

他の交通系ゲームと大きく違う点は、客は「最適経路を知らない」ことです。客は「構内案内」を見て行動します。目的地への経路が存在しても、構内案内を間違えると客は目的地に行けなくて迷います。視界の広さがお客さんによって違い、遠いところに構内案内を置くと、客によっては構内案内を見失って迷います。


駅のホーム、ところどころにある黄色い矢印が構内案内

遠回りで変なシステムに見えますが、よく考えると、すべての客が駅構内の経路を知り尽くしていて、常に最短経路で移動するって変じゃないですか?そんなエスパーみたいな客いませんよね。

正直いって構内案内のメンテナンスはかなり面倒ですが、ゲームとして理不尽にならないレベル(※)で現実に寄せた、素敵なアイデアだと思います。

(※)実世界だと、構内案内をあえて無視して迷う、目の前の構内案内に気づかない、話の通じないクレーマー、など不条理ばかりですが、そんなの再現してもクソゲーにしかなりません。現実に寄せれば良いってものじゃない。

システム紹介: ランクアップと構内施設

乗降客数が増えて、お客さんの不満が少ないとランクアップし、ホームと改札口が勝手に増えます。大抵は予想していない変なところにホームが勝手に増えるので、駅のレイアウトと合わなくなります。つじつま合わせが必要です。ここは腕の見せどころです。

ランクアップに伴い、トイレやレストランなどの構内施設の種類が増えます。エスカレーターしか乗らない高齢客、エレベーターしか乗らない車いす客、などお客さんのバリエーションも増えます。序盤は簡単で、ランクアップによって難易度が段々上がっていく設計に見えます。

ホームと改札の位置はマップにより固定のようです。最後まで進めて最初からやり直せば、綺麗な駅が作れるかもしれません(まだそこまで見てないので断言はできませんけど)。

メモ: 技術系の話は Facebook から転記しておくことにした。加筆&修正した。

[編集者: すずき]
[更新: 2020年 5月 23日 03:16]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

航空科学博物館を支援

Twitter で「収入ほぼゼロ」「来館者9割減」 危機に陥っている「航空科学博物館」がクラウドファンディングで支援募集 - ねとらぼ、の記事を目にしたので、微力ながら 5,000円を支援しました。後で入場券が 2枚送られてくるそうな。

100万円のコースはさすがに高すぎなのか支援者がまだ現れていませんが、30万円のコースは 3人ほど支援者がいました。愛されていますね。

公営の博物館(公益財団法人 航空科学博物館)は、国や自治体が支援するのが筋だろう、という意見も目にしましたし、言い分はわかるんですが、うだうだ言っている間に潰れてしまっては元も子もないです。クラウドファンディングで助けを求めるのは良い手段だと思います。

[編集者: すずき]
[更新: 2020年 5月 23日 02:56]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

GCC を調べる - その 10-2 - ベクトル型への対応

前回(2020年 3月 27日の日記参照)の調査により、targetm.vector_mode_supported_p() が false を返すことが原因だとわかりました。この関数ポインタが指す先は、アーキテクチャターゲット(ARM とか i386 とか riscv とか)ごとに違います。RISC-V の場合は下記のようにすれば良いです。

vector_mode_supported_p の追加

// gcc/config/riscv/riscv.c

static bool
riscv_vector_mode_supported_p (machine_mode mode)
{
  if (TARGET_VECTOR)  //★★本当は mode の値を確認したほうが良いが、今回は手抜き
    return true;

  return false;
}

...

#undef TARGET_VECTOR_MODE_SUPPORTED_P
#define TARGET_VECTOR_MODE_SUPPORTED_P riscv_vector_mode_supported_p

この targetm もやや魔界感があるので、何でこの define で実装が切り替わるのか、についても調べたいところですね。それはさておいて、上記の実装を追加すると無事ベクトル型が使えるようになります。

追加後の 236r.expand の抜粋

(insn 70 2 69 2 (set (reg:V64SI 105 [ v1 ])  ★★reg:V64SI になっている
        (asm_operands/v:V64SI ("vlw.v %0, %1") ("=&v") 0 [
                (mem/c:SI (plus:SI (reg/f:SI 99 virtual-stack-vars)
                        (const_int -360 [0xfffffffffffffe98])) [1 b+40 S4 A64])
            ]
             [
                (asm_input:SI ("A") b.c:7)
            ]
             [] b.c:7)) "b.c":7:2 -1
     (nil))

バイナリも正しく出力されます。sizeof(v1) も 256 が返されます。ちなみにアセンブルしなくても、オプション -S でアセンブラを見てもほぼ同じです。

追加後のバイナリ
a.out:     file format elf32-littleriscv

Disassembly of section .text:

00010054 <_start>:
   10054:       7165                    addi    sp,sp,-400
   10056:       103c                    addi    a5,sp,40
   10058:       1207e007                vlw.v   v0,(a5)
   1005c:       6159                    addi    sp,sp,400
   1005e:       8082                    ret

良かった良かった。オプション O0 の問題はまた今度です。

[編集者: すずき]
[更新: 2020年 5月 17日 22:42]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

GCC を調べる - その 10-1 - ベクトル型を使うとエラー

以前(2020年 3月 27日の日記2020年 3月 28日の日記2020年 3月 29日の日記参照)ベクトルレジスタを扱えるようにした際に、下記の問題が残っていました。

  • 変数が int なので sizeof(v) が 4 になる、ベクトルを扱いたい
  • 最適化オプションを O0 にするとコンパイラが internal error を出す

前回(2020年 5月 12日の日記参照)はベクトル型に向けてマシンモードを追加しました。引き続き、1つ目の問題に取り組んでいきたいと思います。

ベクトル型は基本型(SI, DI, SF, DF など)が複数連結されているデータ型です。個数は 2のべき乗(2, 4, 8, 16, ...)でなければなりません、3 個や 10 個はダメです。型は通常 GCC の実装で定義します。ベクトル型も当然同じで GCC の実装で定義しますが、ベクトル型はやや特殊で、GCC の attribute でも定義することができます。今回は attribute を使ってみます。

ベクトル型を使ったコード

typedef int __v64si __attribute__((__vector_size__(256)));

void _start()
{
	int b[100];
	__v64si v1;

	__asm__ volatile ("vlw.v %0, %1\n"
		: "=&v"(v1) : "A"(b[10]));
}

ベクトル型を使ってインラインアセンブラを書くとエラーが出ます。

ベクトル型を使うと impossible constraint エラー
$ riscv32-unknown-elf-gcc -Wall -march=rv32gcv b.c -O2 -nostdlib -S

b.c: In function '_start':
b.c:7:2: error: impossible constraint in 'asm'
    7 |  __asm__ volatile ("vlw.v %0, %1\n"
      |  ^~~~~~~

このエラーは以前(2020年 3月 6日の日記参照)、register constraint に 'v' を追加したときに解析した部分で見ました。詳細は昔の日記を見ていただくとして、以前との差を示します。

エラーになる箇所

// gcc/recog.c

int
asm_operand_ok (rtx op, const char *constraint, const char **constraints)
{

...

	default:
	  cn = lookup_constraint (constraint);
	  switch (get_constraint_type (cn))
	    {
	    case CT_REGISTER:
	      if (!result
		  && reg_class_for_constraint (cn) != NO_REGS  //★★以前引っかかっていたのはこちら
		  && GET_MODE (op) != BLKmode        //★★今回はこちらの条件に引っかかる
		  && register_operand (op, VOIDmode))
		result = 1;
	      break;

新たなマシンモード V64SImode を追加(2020年 5月 12日の日記参照)を追加したのに、どうして BLKmode が選択されてしまうのでしょう?

オプション --dump-tree-all --dump-rtl-all を付けて、BLKmode が選ばれるタイミングを追うと、パス expand が終わった時点で BLKmode になっていました。

236r.expand の抜粋

(insn 26 7 10 2 (set (mem/c:BLK (plus:SI (reg/f:SI 99 virtual-stack-vars)  ★★mem/c:BLK になっている
                (const_int -1168 [0xfffffffffffffb70])) [1  A128])
        (asm_operands/v:BLK ("vlw.v %0, %1") ("=&v") 0 [
                (mem/c:SI (plus:SI (reg/f:SI 99 virtual-stack-vars)
                        (const_int -872 [0xfffffffffffffc98])) [1 b+40 S4 A64])
            ]
             [
                (asm_input:SI ("A") b.c:7)
            ]
             [] b.c:7)) "b.c":7:2 -1
     (nil))

パス expand は GIMPLE から RTL という中間表現に変換するパスです。RTL に変換した直後から BLKmode ですから、かなり最初の方からダメだってことがわかります。何が悪いかわからないので expand 辺りのコードを探ってみます。

BLKmode になる箇所

// gcc/cfgexpand.c

static void
expand_asm_stmt (gasm *stmt)
{

...

  for (i = 0; i < noutputs; ++i)
    {
      tree val = output_tvec[i];
      tree type = TREE_TYPE (val);
      bool is_inout, allows_reg, allows_mem, ok;
      rtx op;

...

      if ((TREE_CODE (val) == INDIRECT_REF && allows_mem)
	  || (DECL_P (val)
	      && (allows_mem || REG_P (DECL_RTL (val)))
	      && ! (REG_P (DECL_RTL (val))
		    && GET_MODE (DECL_RTL (val)) != TYPE_MODE (type)))
	  || ! allows_reg
	  || is_inout
	  || TREE_ADDRESSABLE (type))
	{

...
	}
      else
	{
	  op = assign_temp (type, 0, 1);  //★★これ
	  op = validize_mem (op);
	  if (!MEM_P (op) && TREE_CODE (val) == SSA_NAME)
	    set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (val), op);

	  generating_concat_p = old_generating_concat_p;

	  push_to_sequence2 (after_rtl_seq, after_rtl_end);
	  expand_assignment (val, make_tree (type, op), false);
	  after_rtl_seq = get_insns ();
	  after_rtl_end = get_last_insn ();
	  end_sequence ();
	}


// gcc/function.c

rtx
assign_temp (tree type_or_decl, int memory_required,
	     int dont_promote ATTRIBUTE_UNUSED)
{
  tree type, decl;
  machine_mode mode;
#ifdef PROMOTE_MODE
  int unsignedp;
#endif

  if (DECL_P (type_or_decl))
    decl = type_or_decl, type = TREE_TYPE (decl);
  else
    decl = NULL, type = type_or_decl;

  mode = TYPE_MODE (type);  //★★これ


// gcc/tree.h

#define TYPE_MODE(NODE) \
  (VECTOR_TYPE_P (TYPE_CHECK (NODE)) \
   ? vector_type_mode (NODE) : (NODE)->type_common.mode)    //★★これ


// gcc/tree.c

/* Vector types need to re-check the target flags each time we report
   the machine mode.  We need to do this because attribute target can
   change the result of vector_mode_supported_p and have_regs_of_mode
   on a per-function basis.  Thus the TYPE_MODE of a VECTOR_TYPE can
   change on a per-function basis.  */
/* ??? Possibly a better solution is to run through all the types
   referenced by a function and re-compute the TYPE_MODE once, rather
   than make the TYPE_MODE macro call a function.  */

machine_mode
vector_type_mode (const_tree t)
{
  machine_mode mode;

  gcc_assert (TREE_CODE (t) == VECTOR_TYPE);

  mode = t->type_common.mode;  //★★このモードは V64SImode になる
  if (VECTOR_MODE_P (mode)
      && (!targetm.vector_mode_supported_p (mode)  //★★この判定文が偽になる
	  || !have_regs_of_mode[mode]))
    {
      scalar_int_mode innermode;

      /* For integers, try mapping it to a same-sized scalar mode.  */
      if (is_int_mode (TREE_TYPE (t)->type_common.mode, &innermode))  //★★256バイトの Int はないから、偽になる
	{
	  poly_int64 size = (TYPE_VECTOR_SUBPARTS (t)
			     * GET_MODE_BITSIZE (innermode));
	  scalar_int_mode mode;
	  if (int_mode_for_size (size, 0).exists (&mode)
	      && have_regs_of_mode[mode])
	    return mode;
	}

      return BLKmode;  //★★BLKmode になってしまう
    }

  return mode;
}

条件式にある targetm.vector_mode_supported_p() が false のため、BLKmode になってしまうようです。

[編集者: すずき]
[更新: 2020年 5月 17日 22:41]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
   2020年 5月 23日 -
      2020年 5月 14日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 5/31 01:18

カレンダー

<2020>
<<<05>>>
-----12
3456789
10111213141516
17181920212223
24252627282930
31------

最近のコメント 20件

  • link 20年05月02日
    すずき 「ちょっと調べたところ、コアが焼けると騒ぎ...」
    (更新:05/08 15:43)
  • link 20年05月02日
    すずき 「結構、怖い制御に見えますね&hellip...」
    (更新:05/08 15:23)
  • link 20年05月02日
    hdk 「デスクトップ用のNVIDIA Quadr...」
    (更新:05/07 20:30)
  • link 20年01月27日
    すずき 「詳細は調べていないので、コード中のコメン...」
    (更新:04/18 23:05)
  • link 20年01月27日
    superzeros 「少し気になったのでglibcの履歴を調べ...」
    (更新:04/16 21:07)
  • link 20年01月27日
    すずき 「コメントありがとうございます。お役に立っ...」
    (更新:04/15 23:13)
  • link 20年01月27日
    superzeros 「ARM64 target (cortex...」
    (更新:04/15 19:59)
  • link 13年11月28日
    すずき 「ご指摘ありがとうございます。投稿の古さに...」
    (更新:03/08 17:39)
  • link 13年11月28日
    yut 「古いので、見てもらえるか不明ですので、、...」
    (更新:03/08 13:16)
  • link 13年11月28日
    yut シムズ 「古い投稿に対して、申し訳ありません。\n...」
    (更新:03/08 13:14)
  • link 19年09月01日
    すずき 「私も正直びっくりです。間違って違う製品を...」
    (更新:09/04 23:39)
  • link 19年09月01日
    hdk 「車向けの製品の中でも、車載コンピューター...」
    (更新:09/02 23:20)
  • link 19年07月18日
    hdk 「あっ、AAMはマニュアルのオペレーション...」
    (更新:07/25 00:02)
  • link 19年07月18日
    すずき 「AAM(ASCII Adjust AX ...」
    (更新:07/24 22:22)
  • link 19年07月18日
    hdk 「加算減算は符号のありなしどちらも命令が同...」
    (更新:07/24 07:25)
  • link 19年07月18日
    すずき 「OFをセットして例外を出したければINT...」
    (更新:07/20 11:02)
  • link 19年07月18日
    すずき 「MUL については、結果が倍のビット幅に...」
    (更新:07/20 10:56)
  • link 19年07月18日
    hdk 「x86の除算例外は8086/8088の頃...」
    (更新:07/20 00:23)
  • link 19年05月17日
    すずき 「試してみたら、同じみたいです。\nわざわ...」
    (更新:05/25 10:35)
  • link 19年05月17日
    hdk 「実際に試したわけではないので素朴な疑問な...」
    (更新:05/23 21:07)

最近の記事 3件

link もっとみる
  • link 20年06月01日
    すずき 「[GCC を調べる - その 13-4 - ベクトル命令のオフ] ...」
    (更新:05/31 01:18)
  • link 20年05月31日
    すずき 「[GCC を調べる - その 13-3 - オフセット付きアド] ...」
    (更新:05/30 22:00)
  • link 20年05月30日
    すずき 「[GCC を調べる - その 13-2 - オフセット付きアド] ...」
    (更新:05/30 21:53)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報