Mercurial > hg > Papers > 2011 > nobu-prosym

comparison presen/advice.txt @ 56:46cc88d1051c

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
add presen/advice.txt
author Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp>
date Sat, 24 Dec 2011 20:58:48 +0900
parents
children
comparison
equal deleted inserted replaced
55:06ce8fb8e278 56:46cc88d1051c
1 Continuation
2 ベーシック
3
4 環境付き継続が普通。
5 schemeとの継続は違う
6 light-weight
7 スタック
8 会議室
9 SICP のContinuation
10
11 Micro-C 2001 年
12 『GCC上の』をつける。
13 『行った~』くらいに。赤いみない。
14
15 難しいところがどこで、どうやって解決し方。
16
17 フルセットのCに
18 C with Continuation
19 それを制限するとContinuation Based Cになる。
20
21 より高度に最適化。。。の部分は外す。
22
23 どのパス
24
25 コンパイラは幾つかパスを通る。
26 そのたんびにTree
27
28 トレースをだす。
29 GCC をいじるというのはどういうことなのかをいいたい。
30 execute_pass_list: 1616
31
32 passes.c:1558
33 execute_one_pass() を読んでないと行けない。
34
35 pass_execute
36
37 pass の前後でデバッグオプションがあるから
38
39 NEXT_PASS はオプティマイゼーションパス
40
41 passes.c:
42 do_per_function()
43 IPAモード関数単位でしかコンパイルしない場合…?。
44
45 NEXT_PASS
46
47 OpenMP 様
48
49 eh = error handler
50 worn_function_return はcbCなのにreturn
51
52 NEXT_PASS (pass_build_ssa);
53
54 昔はGIMPLEは残っていたけど、消されてはまった。
55
56 INter procedure Optimization
57 (ipa)
58
59 CbC だとほとんど使わないはず。
60 なので、CbC で書いたほうが性能が悪くなる可能性がある。
61
62 SSAからgimpleにもどす。
63 昔はいきなりRTLに変換していた　
64 SSAをRTLに変換するルーチン
65
66
67 cse
68 common se… elimination
69 共通部分の最適化
70
71
72 pass の中でコード生成されていたと思うので。
73 最終的にコード生成のところまでいくのはながい。
74
75
76 SSAからgimpleに戻しているところがあるはず…
77 gimple_expand cfg
78
79 pass_expand から
80 call_expand は gimple から rtl を生成しているはず。
81 こっから下は
82
83
84 rtlをSSAに変換しているアホがいる。
85 そこのスライドはこのパスにそって説明する必要がある。
86
87
88 pass_expandから上としたは全然ちがう。
89 call_expandはgimpleだけど途中SSAに変換してgimpleに戻す。
90
91
92 実際にpass_listがあって、そのpass_listの中でexpand_callがどこにあるのかっていうのを説明してほしい。
93 なぜか、プログラミングシンポジウムはハッカーの為の詳細なので、
94 GCCを今いじるならどんなふうにいじるのか。
95
96
97 自分が以下にGCCを理解しているのかを行って欲しい。
98
99
100
101
102 実際は
103 gotoとなってるけど、単にfactorialと書いたのと同じだよね。
104 factorial0()
105
106
107 goto factorial()
108 だとtail recursive call が矯正される。
109
110
111
112 右側のgoto はとる。
113
114
115 実際にどんな引数渡しになるのか。
116 micro-C ベースのやつがレジスタ渡しだったのでださいコンパイラに負けるということになった。
117 Intel64はレジスタが増えた。レジスタ16になったから増えた。
118
119
120
121
122 basic.c は引数渡しに使われるレジスタの数を調べる。
123
124
125 表にする。
126 i386
127 ia64
128
129
130 引数は浮動小数点と整数があるよね。その浮動小数点と整数の２つを。
131
132
133
134
135 環境付き継続がの説明のスライド。
136 本来はクロージャである必要はない。
137 GCCで
138 setjmpで実装しても問題はあまり変わらなくて。
139 それでどうなるか、static を使うと
140 thread local な static だったらうまくいくのでは。
141
142
143 setjmpでない普通のやつを先に。
144 setjmpのソースは
145 どうやって生成しているかのソースを内部的に生成しているのをみせてもいいと。
146
147
148 問題は return val 。だから意味がない。
149 setjmp
150 重要なのはretval。
151 これでない
152
153
154 問題はreturn val がmainの中の環境にある。
155 これが普通のローカル変数だと、tail recurcive でぬけると駄目になる。だからstatic にしないといけない。
156 static にすればこれを
157 なぜまずかったのか。mainから tail recursive call で抜けてるからまずい。普通にcallすれば生きてるので、
158 クロージャを使ってうまくできると…
159
160
161 mainで抜ける所で
162 goto は二種類。
163 普通の関数からgotoする場合。
164 コードセグメントからgotoする場合で実装が違う。
165
166
167 statci tls をスレッドローカルにすればいんだけど、実際には決まったレジスタにすればいい。
168 レジスタとは->リターンするレジスタ
169
170
171 書きこむ先は相手側にあるので関係ない。
172 それをそっちの方にコピーするってのはどっかそのへんでやっている。
173 多分return 文の中でコピーする。
174 return は
175 正しく構造体の戻り値を指していればいいだけで、
176
177
178 引数がついている。
179 構造体の場合は引数で一個呼ばれているのでその引数をとっておかないといけなくて。
180 実は引数、 evnpがついてる。
181 値を返す evnp がさしてる allocate させてるところにおいてもいい。
182
183
184 evnpni
185
186
187 Micro-C ではフレームポインタが入っている。
188 実装ではフレームピオンタが入っている。
189
190
191 さっき行ったとおり、return val はレジスタでいいので、return レジスタ
192 simple return;
193 return だけで戻る。
194 前にレジスタを設定したので戻ってくると。
195
196
197 関数の戻りからの動作はおもいので、
198 goto 剃る前にはレジスタの値がきまっているはず。
199
200
201 return val があればbuild1 で
202
203
204 if(0)なので中にはいってこない。このコードが最適化で消えないように工夫しないといけない。
205 最適化をかけるとここがきえちゃう。消えないようにCOND をいれて〜とかある。
206
207
208 cbc_exit0: が外から
209 TREE_used とか
210 c_decl_flag_label
211
212
213 最適化で消えちゃわないようになってる。
214
215
216 最適化かけてうまく動かなかいのはこのコードが消されちゃうから。
217 そのあたりをチェック。
218
219
220 setjmp 使えば常にもどれるので。
221 CbCのなかでsetjmp してlongjmp をかいてももどれる。
222
223
224
225
226 CbC バージョン GCC バージョン
227 typedef
228
229
230 __rectype
231 __selftype
232
233
234 それを入れるためにはどうすればいいのかっていうのも議論すればいい。
235
236
237 typdef をやると、先輩たちがやって
238 もちろん両方。
239