YAMAMOTO Kengo / YamaKen
yamak****@bp*****
2006年 7月 8日 (土) 14:01:09 JST
At Sat, 08 Jul 2006 09:18:53 +0900, gniib****@m17n***** wrote: > > YAMAMOTO Kengo / YamaKen wrote: > > i386 gccの場合は-Osを付けない限り速度優先で揃えてくれるようだっ > > たのでそれで済ませていましたが、aligned attributeあたりで何とか > > できないか試してみます。 > > あー、ここ、"-Os" についてですが、認識が違うと思います。 > autoconfのメッセージも検討するのが良いと思います。 > > と、言うのは、一般に(今回は -Os ですけど) > > オプティマイズによってデータ構造のメモり表現が変わることはない > > からです。あるいは、 > > オプティマイズによってデータ構造のメモり表現が変わっては困る > > と言いましょうか。 > > データ構造のメモリ表現は ABI の一部で C では分割コンパイルが前提ですか > ら、オプティマイズによって ABI が変わると、全てのコンパイルをある特定の > オプティマイズオプションにそろえる必要があることになると思います。 > > ある .o がデータ構造のメモリ表現 A を仮定していて、また別の .o は > これと異なるデータ構造のメモリ表現 B を仮定している場合、これらをリンク > すると動かないですよね。 ご指摘ありがとうございます。この辺はちょっと考察が粗雑だったし、 自分自身による実験も足りなかったのでやり直しました。 structやunionの中での先頭アドレスからの相対位置については上記の 通りなんですが、スタック上で他のオブジェクトと並べられた時の絶対 アドレスがword alignedでないケースを想定していました。以下のよう なコードでl1がlong境界に揃わないような。 void f(void) { long l0; char c[2]; long l1; ... } そして、このアライメントに -Os が影響すると思い込んでいました。 「-Osを付けると関数アドレスがalignされない」という情報を自分で実 験もせずに「-Osだからメモリ節約のため余計なpaddingを入れない。ス タック上でも同様」と脳内変換してしまっていたようです。しかし、実 際に手元のgcc 4.1(i386)で確かめてみると以下のようになりました。 スタック上のlong: -Os, -O0, -O1, -O2, -O3とも4byte aligned 関数: -Os, -O0, -O1はアライメントなし(奇数アドレスあり) -O2, -O3は16byte aligned この結果から、 ・i386上の-Oxはデータのアライメントには影響なし ・関数には影響するが、「-Osを付けるとアライメント無し」ではなく 「-O2と-O3の場合はキャッシュラインに揃える」が正しい という事が分かったので、configureのメッセージも修正しておきまし た。gcc 4.1では上記のコードはサイズ毎にデータが集約されて reorderingが発生してしまうんですが、一応テストに追加しておきまし た。 m68kの方は全く解決してないんですが、nativeな68k環境なんてPalmぐ らいしか持ってないので -S で目視デバッグですかね。 > Debian は現在のところ native ビルドが前提で、upload されたパッケージは > 全てのアーキテクチャで native ビルドされます。 > > 今後も変わらないと思います。ここを cross にするという野望がありますが、 > それは別の話。 なるほど。情報どうもです。SigScheme的にはshあたりが入ってくれる と嬉しいですね。 ------------------------------------------------ YAMAMOTO Kengo / YamaKen yamak****@bp***** FAMILY Given / Nick
