コグノスケ

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

目次: GCC

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

;;★★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を出力した瞬間に実行が止まります。

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

(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() が怪しそうです。次回以降、この関数を中心に調べます。

GCCを調べる - その11-1 - オプションO0のエラー調査（define_expand追加編）

目次: GCC

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

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

いよいよコンパイラがInternal compile errorを出す問題に取り組みます。ベクトル型を使ったインラインアセンブラを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を比べます。

;;★★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))

...

;;★★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のとき

(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がどこから来るのか調べます。

さようならSeaMonkey

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

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

こんにちはFirefox

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

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

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

STATIONflow始めました、超えろ、新宿駅

目次: ゲーム

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

STATIONflowロゴ

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

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

良いところ、嫌なところ

（気に入ったところ）

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

（気に入らないところ）

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

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

ゲームシステム紹介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

航空科学博物館を支援

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

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

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

GCCを調べる - その10-2 - ベクトル型への対応（TARGET_VECTOR_MODE_SUPPORTED_P追加編）

目次: GCC

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

// 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で実装が切り替わるのか、についても調べたいところですね。それはさておいて、上記の実装を追加すると無事ベクトル型が使えるようになります。

(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の問題はまた今度です。

GCCを調べる - その10-1 - ベクトル型を使うとエラー（TARGET_VECTOR_MODE_SUPPORTED_P追加編）

目次: GCC

以前（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]));
}

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

$ 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になっていました。

(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辺りのコードを探ってみます。

// 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になってしまうようです。

ノートPCのファンがうるさい

ノートPC（ThinkPad E480）の冷却ファンが回り続けていてうるさいです。特に何かしている訳でもないのに、良い勢いでファンが回ってます。

ここ最近、ノートPCを酷使（ゲーム、在宅勤務など）したため、ファンに埃が詰まって、冷却能力が下がったか？と予想して、頑張ってThinkPadの裏蓋を開けました。しかし思ったほど汚れていません。

どうしてファンが回りっぱなしなんでしょう？純粋に冷却能力が足りないだけなんだろうか？？

ThinkPadの裏蓋

ThinkPad E480の裏蓋はめちゃくちゃ開けにくいです。ネジ9か所と爪で止まっているので、ネジを緩めた後、マイナスドライバーでこじ開けるしかありません。

爪を外すとき、バキっ！ベキっ！というすごい嫌な音がします。案の定、ヒンジ付近（ノートPCとノートPCディスプレイが接続されている方）の爪が4か所ほど折れました。

GCCを調べる - その9 - ベクトル型用マシンモードの追加

目次: GCC

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

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

1つ目の問題に取り組んでいきたいと思います。RISC-V 32の場合、intの変数は32bit整数のデータ型として扱われます。GCC内部の表現（RTL）ではSImodeというマシンモード（※）で表されます。他の大きさのデータ型を示すマシンモードも当然存在していて8, 16, 64bit整数はそれぞれBImode, HImode, DImodeで表されます。

普通の型に対応するモードはGCCが定義済みですが、ベクトル型を表すモードは標準では存在しないため、自分で新規に定義する必要があります。

（※）マシンモード（Machine Mode）については、GCC Internalsの14.6 Machine Modesに簡単な説明と標準的なモードの一覧が載っています。これによればSIはSingle Integerの略らしいです。変な名前だなあ。

マシンモードはどこにある？

以前（2020年3月14日の日記参照）説明したとおりですが、軽くおさらいすると、標準的なマシンモードはgcc/machmode.def、アーキテクチャ固有のマシンモードはgcc/config/arch/arch-modes.defにあります。例えばRISC-Vならgcc/config/riscv/riscv-modes.defです。

現在のところRISC-V固有のマシンモードは1つしか定義されていません。

FLOAT_MODE (TF, 16, ieee_quad_format);

このファイルにベクトル型を表すマシンモードを追加します。

VECTOR_MODE (INT, SI, 8);
VECTOR_MODE (INT, SI, 16);
VECTOR_MODE (INT, SI, 32);
VECTOR_MODE (INT, SI, 64);

とりあえず整数（INT, SI）が8, 16, 32, 64（それぞれ32, 64, 128, 256バイト）個連結されているデータ型を想定して作りました。ベクトル型を語る上では浮動小数点型も大事ですが、とりあえず今回は整数型のみを定義しています。

マシンモード追加できたかな

マシンモードを正しく追加できたか確かめる方法は色々あるのでしょうけど、個人的に簡単だと思うのは一旦ビルドしてしまう方法です。

GCCをビルドするとビルド用のディレクトリ（以降build_gccと呼びます）に、モードが全部書いてあるヘッダinsn-modes.hが生成されます。生成されたヘッダを検索すれば一発です。

// gcc/build_gcc/insn-modes.h

enum machine_mode
{
  E_VOIDmode,              /* machmode.def:189 */
#define HAVE_VOIDmode
#ifdef USE_ENUM_MODES
#define VOIDmode E_VOIDmode
#else
#define VOIDmode ((void) 0, E_VOIDmode)
#endif
  E_BLKmode,               /* machmode.def:193 */
#define HAVE_BLKmode
#ifdef USE_ENUM_MODES
#define BLKmode E_BLKmode
#else
#define BLKmode ((void) 0, E_BLKmode)
#endif

...

  E_V32SImode,             /* config/riscv/riscv-modes.def:26 */
#define HAVE_V32SImode
#ifdef USE_ENUM_MODES
#define V32SImode E_V32SImode
#else
#define V32SImode ((void) 0, E_V32SImode)
#endif
  E_V64SImode,             /* config/riscv/riscv-modes.def:27 */
#define HAVE_V64SImode
#ifdef USE_ENUM_MODES
#define V64SImode E_V64SImode
#else
#define V64SImode ((void) 0, E_V64SImode)
#endif

...

新たなマシンモードV64SImode（SIが64個連結されたデータ型）が追加されたことがわかると思います。コメントにマシンモードの定義されている場所も書かれていて、とても親切です。

ほぼ全域に渡って意味不明コードだらけのGCCでは珍しい部類の、わかりやすさ＆親切さです。自動生成コードには気を使っているんでしょうか？他のところもこれくらい親切だと嬉しいんですけどねえ。

ヤマザキ春のパン祭り

今年のヤマザキ春のパン祭りは、2枚もゲットできました。

2020年、春のパン祭りの戦利品

去年は品川勤務かつコンビニ昼飯がメインだったので、ヤマザキパンを買う機会がほぼなく、お皿をもらえるほど点がたまりませんでした。今年はCOVID-19による在宅勤務で、近所のスーパーでパンを買う機会が大幅に増えたため、2枚も手に入ったわけです。在宅勤務の意外な効果です。

コンビニに行かない人にとっては意外かもしれませんが、コンビニはヤマザキパンをほとんど置いていません。自社のプライベートブランドのパンばかりです。10年位前は他社のパンも置いていたんですが、今やコンビニは9割方がプライベートブランドのパンです。

コンビニのプライベートブランドのパンは、大手メーカー（ヤマザキパン、敷島製パン、フジパンなど）が作っていますが、コストの都合か何だか知りませんが、味に劣る気がします。好みの問題なのかな……？

強化ガラス

パン祭りのお皿、裏側に何か書いてるなーと思って写真を撮ってみました。

お皿の裏の説明

ちょっと見づらいので文字に起こすと、

ARTICLE YAMAZAKI
MADE IN FRANCE

ZENMEN
BUTSURIKYOUKA
GARASU

「全面物理強化ガラス」ってローマ字で書いてありますね。フランス製なのに何でローマ字？フランス語で書かれても読めないから？

見ていて素朴な疑問が沸きました。あえて「全面」と強調する理由はなんでしょうね？皿のように厚みのない製品で「片面」物理強化ガラスにすることは可能？可能だったとしてもやる意味がある？

Pythonの変なAPI

Pythonの文字列置換は "string".replace() ですが、正規表現ライブラリreだと、なぜかre.sub() です。同じ機能なのに、APIの名前も、引数の指定順序も違います。どうしてこうなった。

改定の度に魔界化するC/C++ に比べると、Pythonは明瞭に思えます。とはいえPythonも何だかんだ長い歴史ですし、祓いきれない闇があるんでしょうねえ。

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