コグノスケ


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

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

2020年5月16日

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

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

ベクトル型を使うと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になってしまうようです。

編集者:すずき(2023/09/24 11:49)

コメント一覧

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



2020年5月17日

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

目次: GCC

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

編集者:すずき(2023/09/24 11:49)

コメント一覧

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



2020年5月18日

航空科学博物館を支援

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

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

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

編集者:すずき(2020/05/23 02:56)

コメント一覧

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



2020年5月19日

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

目次: STATIONflow

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


STATIONflowロゴ

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

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

良いところ、嫌なところ

(気に入ったところ)

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

(気に入らないところ)

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

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

ゲームシステム紹介

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

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

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

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

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


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

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

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

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

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

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

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

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

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

編集者:すずき(2020/09/09 10:38)

コメント一覧

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



2020年5月21日

さようならSeaMonkey

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

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

こんにちはFirefox

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

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

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

編集者:すずき(2020/05/23 02:45)

コメント一覧

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



2020年5月22日

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

目次: GCC

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

編集者:すずき(2023/09/24 11:49)

コメント一覧

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



2020年5月23日

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

目次: GCC

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

編集者:すずき(2023/09/24 11:49)

コメント一覧

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



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

管理用メニュー

link 記事を新規作成

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

最近のコメント5件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」

最近の記事20件

  • link 24年3月25日
    すずき (03/26 03:20)
    「[Might and Magic Book One TASのその後] 目次: Might and Magicファミコン版以前(...」
  • link 21年10月4日
    すずき (03/26 03:14)
    「[Might and Magicファミコン版 - まとめリンク] 目次: Might and Magicファミコン版TASに挑...」
  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
  • link 23年4月10日
    すずき (03/19 11:48)
    「[Linux - まとめリンク] 目次: Linuxカーネル、ドライバ関連。Linuxのstruct pageって何?Linu...」
  • link 24年3月18日
    すずき (03/19 11:47)
    「[画面のブランクを無効にする] 目次: LinuxROCK 3 model CのDebian bullseyeイメージは10分...」
  • link 24年3月3日
    すずき (03/19 11:07)
    「[解像度の設定を保存する] 目次: LinuxRaspberry Pi 3 Model B (以降RasPi 3B)のHDMI...」
  • link 24年3月14日
    すずき (03/16 23:03)
    「[JavaとM5Stamp C3とBluetooth LE - Bluetoothデバイスとの通信] 目次: ArduinoM...」
  • link 24年3月8日
    すずき (03/16 23:03)
    「[JavaとM5Stamp C3とBluetooth LE - BluetoothデバイスとServiceの列挙] 目次: A...」
  • link 23年6月2日
    すずき (03/16 21:11)
    「[Arduino - まとめリンク] 目次: Arduino一覧が欲しくなったので作りました。 M5Stackとesp32とA...」
  • link 23年5月15日
    すずき (03/16 00:57)
    「[車 - まとめリンク] 目次: 車三菱FTOの話。群馬県へのドライブ将来車を買い替えるとしたら?FTOのオイル交換とオイル漏...」
  • link 24年3月9日
    すずき (03/16 00:56)
    「[車のバッテリー完全に死亡で交換かと思いきや] 目次: 車またまた車のバッテリーが干上がって死にました。写真は撮っていませんが...」
  • link 24年3月10日
    すずき (03/15 03:34)
    「[誕生日] 早いもので41歳になりました。昨年の日記(2023年3月10日の日記参照)を見ると、コロナの流行を心配していました...」
  • link 24年3月6日
    すずき (03/12 01:18)
    「[Raspberry Pi 3 model Bの代わりにROCK 3 model C] 目次: Arduino最近、M5Sta...」
  • link 24年3月4日
    すずき (03/06 00:09)
    「[volatileをnon-volatileで参照してはいけない] 目次: GCC過去の日記(2021年3月13日の日記参照)...」
  • link 20年6月2日
    すずき (03/06 00:06)
    「[GCC - まとめリンク] 目次: GCCGCCについて。GCCを調べる - その1 - ビルドGCCを調べる - その2 ...」
  • link 15年5月9日
    すずき (03/05 03:00)
    「[自作ARMエミュレータ - 今さら気づいたブートローダのバグ] 目次: Linuxずっと気づいていなかった自作ARMエミュレ...」
  • link 23年6月1日
    すずき (03/05 02:59)
    「[自宅サーバー - まとめリンク] 目次: 自宅サーバーこの日記システム、Wikiの話。カウンターをPerlからPHPに移植日...」
  • link 15年5月3日
    すずき (03/05 02:59)
    「[GRUB2が起動しなくなってしまった] 目次: 自宅サーバーサーバにインストールしていたDebian 32bit版 のJes...」
  • link 15年5月2日
    すずき (03/05 02:58)
    「[systemdを使うのをあきらめた] 目次: 自宅サーバー独自ビルドのカーネルだと/sys/fs/cgroupが無いと言われ...」
  • link 15年4月30日
    すずき (03/05 02:56)
    「[Debian 8.0 Jessie] 目次: 自宅サーバーDebianのアップデートが来ていたので、試しに職場のPCをアップ...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
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 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

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

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/26 03:20