まだまだ開発中のコードでも、必要な間隔でパルスが出るかとか期待以内でループが回るかを確かめたいとき、全体で最適化掛けてしまうとデバッグしにくかったんです。
で、ターゲット依存とかコンパイラ依存とかの関係か、いまいち資料や情報があやふやな感じで敬遠気味だった #pragma での最適化を試してみました。
まず動機は次の 2 点
・まだまだ全体はデバッグモードでやりたい
・特定の場所での処理時間を知りたい
もちろん問題の箇所はデバッグ版の最適化なしだと期待した時間内に処理できなくて、最適化 -O2 のリリース版なら間に合うのがわかっていました。でなきゃそもそも無理・・・。
これが出来ると、デバッグ中でも必要な所だけは全力で走れそうです。
なお、どうやら #pragma での最適化は関数ごとに設定するようで、特定のループだけ、なんかには使えない様子でした。
書き方
#pragma GCC push_options // 現在の設定を一旦退避
#pragma GCC optimize("O2") // optimize more を指定
void hoge(void) {
for (int I = 0 ; I < n ; I++) {
...
}
}
#pragma GCC pop_options // 退避した設定を復帰
この時、optimize のところは () との間にスペースがあっても、"O2" を "-O2" と (コマンドラインオプションっぽく) 指定しても OK です。
オプションの詳しい情報は https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas あたりに。
また、「この関数にだけ」効くので、ここから他の関数を呼んでいると台無しです。ここ大事です。
特にポートアクセスなどの inline 関数は、デバッグモードでは関数呼び出しに展開されているので、「あれ?ぜんぜん効かない・・・」って事になるので要注意です。
なお今回は push_options / pop_options の効果を充分確認できるところまで詰めていないので、こいつらは効いているのかどうかよくわかりません・・・(^_^;)。
で、ターゲット依存とかコンパイラ依存とかの関係か、いまいち資料や情報があやふやな感じで敬遠気味だった #pragma での最適化を試してみました。
まず動機は次の 2 点
・まだまだ全体はデバッグモードでやりたい
・特定の場所での処理時間を知りたい
もちろん問題の箇所はデバッグ版の最適化なしだと期待した時間内に処理できなくて、最適化 -O2 のリリース版なら間に合うのがわかっていました。でなきゃそもそも無理・・・。
これが出来ると、デバッグ中でも必要な所だけは全力で走れそうです。
なお、どうやら #pragma での最適化は関数ごとに設定するようで、特定のループだけ、なんかには使えない様子でした。
書き方
#pragma GCC push_options // 現在の設定を一旦退避
#pragma GCC optimize("O2") // optimize more を指定
void hoge(void) {
for (int I = 0 ; I < n ; I++) {
...
}
}
#pragma GCC pop_options // 退避した設定を復帰
この時、optimize のところは () との間にスペースがあっても、"O2" を "-O2" と (コマンドラインオプションっぽく) 指定しても OK です。
オプションの詳しい情報は https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas あたりに。
また、「この関数にだけ」効くので、ここから他の関数を呼んでいると台無しです。ここ大事です。
特にポートアクセスなどの inline 関数は、デバッグモードでは関数呼び出しに展開されているので、「あれ?ぜんぜん効かない・・・」って事になるので要注意です。
なお今回は push_options / pop_options の効果を充分確認できるところまで詰めていないので、こいつらは効いているのかどうかよくわかりません・・・(^_^;)。