Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
上下前次1-新
287: 2025/10/11(土)00:12 ID:e8fGXa5a(1) AAS
ADDではなくLEAでフラグ変化させずに加算演算するのは手動でもコンパイラでも基本
この常識を理解できない低レベルな人はコード書いたりコンパイラ生成コードを見たことすらない人
288: 2025/10/11(土)10:05 ID:mX/iHQDj(1/2) AAS
コンパイラが出力した「条件フラグを変更せず保持したまま演算を行なう」コードの実例から逃げてるとこ見ると「LEAで加算ができる」が知識の限界の人かな
289: 2025/10/11(土)10:12 ID:mX/iHQDj(2/2) AAS
> コンパイラ生成コードを見たことすらない人
このスレでCompiler Explorerのアドレス貼ってる人は珍しくないので（>>150とか）同様にして見せてやれば良い。
290(1): 2025/10/12(日)03:13 ID:obnnOjq+(1) AAS
Rust信者ってこんなもんだなあとういうのはまあ納得
291: 2025/10/12(日)03:35 ID:Iv4aWOmO(1) AAS
Rust？
関係ないだろ
292: 2025/10/12(日)05:25 ID:D80drn0C(1) AAS
マシン語にするプログラミング言語は最適化によって意図と違うコードになることがあるという話をしたいんだろ。
293: 2025/10/12(日)12:59 ID:EE9svh1n(1/2) AAS
> Rust？
> 関係ないだろ
>>275からの話の流れが理解できない人かな
294: 2025/10/12(日)19:07 ID:txsY3oX4(1/2) AAS
>>275
このRustプログラムが最適化あり（リリースビルド）／最適化なし（デバッグビルド）で挙動が変わる理由は、i8型の符号付き整数オーバーフローの扱い方が状況によって異なるためです
最適化なし（デバッグビルド）
sum += numで加算の結果がi8の範囲（-128～127）を超えてしまうと、panicになるため意図した出力が得られず、エラーが発生します
最適化あり（リリースビルド）
オーバーフローのチェックが省略されて二の補数によるラップアラウンド（桁あふれの結果として範囲内に収める計算）が行われます
295: 2025/10/12(日)19:15 ID:txsY3oX4(2/2) AAS
リリースビルド（最適化あり）でもオーバーフローを検出し、デバッグビルド（最適化なし）と同じ挙動にする方法があります
Cargo.tomlに以下を追記します：
[profile.release]
overflow-checks = true
リリースビルドでも整数オーバーフローが発生するとpanic（異常終了）になります
296: 2025/10/12(日)20:41 ID:VrekPvIE(1/2) AAS
デフォで安全側に倒してない時点で残念言語だな
297: 2025/10/12(日)21:03 ID:UHx3WDzt(1/2) AAS
オーバーフローでプログラムを中断したいのか
オーバーフローをエラーとして返したいのか
オーバーフローを値として受けて活用したいのか
オーバーフローは影響しない処理なのか
一般的に様々な状況が考えられる
これは安全性の問題とは関係がない
298(1): 2025/10/12(日)21:59 ID:VrekPvIE(2/2) AAS
> オーバーフローでプログラムを中断したいのか
> オーバーフローをエラーとして返したいのか
> オーバーフローを値として受けて活用したいのか
> オーバーフローは影響しない処理なのか
> 一般的に様々な状況が考えられる
話についてこれない人かな
299: 2025/10/12(日)22:06 ID:UHx3WDzt(2/2) AAS
>>298
オーバーフローをどう処理したいかはプログラミングの内容に依って変わる
これは安全性の問題ではない
300: 2025/10/12(日)22:47 ID:EE9svh1n(2/2) AAS
オーバーフローを無視して処理を続けていいわけはないので安全性の話なんだよなあ
何言ってんのこの人ｗ
301: 2025/10/12(日)22:55 ID:jaSkqZ+M(1) AAS
オーバーフローは無視できる処理もあるし、オーバーフローが起きない場合もあるわけだから、そこはケースバイケースやろ。
状況次第としか。
302: 2025/10/12(日)23:07 ID:yC0+QvH7(1) AAS
生成コードで考えると
オーバーフローフラグが立つ演算命令1つ毎に直後にオーバーフローの有無で判断する分岐命令を必ず入れることになるがそれは効率が悪すぎる
しかも命令順序の固定化と直列化を招いてしまう
現在のCPUは命令順序の入れ替えと並列化で最適化をするからそれができないと劇的に遅くなる
不要なオーバーフローチェックは可能な限り避けるべき
303: 2025/10/13(月)02:39 ID:5mcGe2/B(1) AAS
>>290
オーバーフローのチェックのコストの重さ問題は特定の言語に関係なく全ての言語で生じる話だよ
そのためC/C++ Java Go Rustなど多くの言語では標準状態でオーバーフローのチェックは行われずラップアラウンドされた結果となるよ
そして必要に応じてオーバーフローのチェックをする関数を呼び出すなどして対応するよ
304: 2025/10/13(月)02:43 ID:eGOGeFhV(1) AAS
最適化のなしかありかで挙動の変わると言ったのが間違い
最適化でなくオーバーフローチェックのなしかありかで挙動の変わる
デフォで安全側に倒してないと言ったのも間違いでデフォでデバッグビルドを作って安全側に倒してオーバーフローチェックがある
劇的に遅くなるからリリースビルドのデフォでオーバーフローチェックがないのは妥当
305: 2025/10/13(月)09:36 ID:wFHYv9H9(1) AAS
配列アクセスで範囲チェックしてくれる言語についてオーバーフローチェックは「効率ｶﾞｰ」と発狂してるのｵﾓﾛｲｗ
お前らRustも実行効率もなんも分かってないなｗ
306: 2025/10/13(月)16:43 ID:4KhFq0Un(1) AAS
配列アクセスでの範囲チェックはメモリ安全性の一つであり必須事項
コンパイラが範囲内であると判断できれば最適化で安全にチェックをなくすことが可能
さらにRustなどではシーケンシャルアクセスの場合にインデックスアクセスが使われないため安全性と実行効率を両立させている
上下前次1-新書関写板覧索設栞歴
あと 462 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.026s