問題タブ [restrict-qualifier]

ようやく C99 のいくつかの機能に興味を持ちましたが、C99 ドラフトの関連セクションを理解するのに苦労しています。

restrict は、restrict 修飾された 2 つのポインターが同じオブジェクトを指さないという約束であることは知っていますが、許可されているものと許可されていないものについて、より詳細で具体的な説明を見つけるという私の探求はほとんど成果を上げていません。

したがって、私の質問は次のとおりです。制限ポインターに関する詳細について、誰かが読みやすく理解しやすい説明を提供できますか。たとえば、それらを使用できる場合と使用できない場合、UB の場合などです。詳細なほど良いです。C99のドラフトを見て頭が痛くなるのはうんざりです。

ありがとう。

次のプロトタイプ間に実際的な違いはありますか?

セクション C11 6.7.6.3/15 (最終文) では、トップレベル修飾子は型の互換性を判断する目的では考慮されない、つまり、関数定義がそのパラメーターにプロトタイプとは異なるトップレベル修飾子を持つことが許可されていると述べています。宣言がありました。

ただし、(C++ とは異なり) 完全に無視されるとは言いません。この場合、const明らかに議論の余地があります。ただし、場合によってvolatileはrestrict違いがあるかもしれません。

例：

プロトタイプに が存在restrictすることで、コンパイラはaforの読み取りを最適化できreturn a;ますか?

(関連する質問)

ベクトル化を目的とした次の関数を検討してください。

もちろん、srcとdstがエイリアスされていない場合、これは機能します。しかし、src == dst の場合はどうでしょうか? もちろん、src == dst+1 などの極端なケースは許可されません。しかし、ポインターが同じであれば、問題はないはずです。それとも、何か不足していますか?

編集: restrict は Intel C++ コンパイラのキーワードで、MSVC には __restrict があります。

この質問に対する私のポイントは、あらゆる種類のベクトル化がどのようにうまくいかないかがわかりません. dst が変更された場合、src 値が書き込まれたという事実は出力が計算されたことを意味するため、src 値はもう必要ありません。唯一のケースは、コンパイラが dst 自体を一時バッファとして使用した場合であり、これは正しくないと思います。

restrictC99 に追加されたキーワードの主な用途の 1 つは、コンパイラが何かをレジスタにロードし、レジスタがロードされた変数の状態を反映すると想定できるようにすることです。与えられた

(*b)コンパイラーは、 への書き込みが に影響を及ぼさないと想定する権利があるため、書き込み後(*a)に再ロードする必要がなくなり(*a)ます。restrictエイリアシングに他の影響はありますか? たとえば、次のようになります。

コンパイラは、 のインクリメント、および*qへの呼び出しがすべて を妨害した可能性があること、および呼び出しがおよびの値に「関心がある」可能性があることを予測する必要がありますか? コンパイラは、 への呼び出しがそのパラメータを永続化した可能性があると想定する必要がありますか?foo2a()foo2b()xx*qfoo2a()restrictfoo2b()z

キーワードにもかかわらず、コンパイラーが最悪の場合の仮定の下で動作する必要がある場合restrict、コンパイラーが関数呼び出しの前に特定の変数への変更を保存し、次回それをリロードする通常の義務を無視する許可を与える方法はありますか?それは必要ですか？

restrictgcc 5 も clang 3.6も、 で呼び出された場合でも、修飾子の制約に違反している場合に警告を発しません-Wall。次のコード フラグメントを検討してください。

-Wall単純に、違反は静的に判断できると予想し、警告が表示されることを期待していました。どこかでフラグを見逃したのでしょうか、それとも表示されていない警告を出すことに何か問題がありますか?

私のポインターはすべて重複しないメモリを指しているため、可能な限り、カーネル (およびそのインライン関数) に渡されたポインターをrestrictedに置き換え、const にもしました。ただし、これにより、一部のカーネルのレジスタ使用量が増加し、他のカーネルでは減少しました。これは私にはあまり意味がありません。

なぜこれが当てはまるのか誰か知っていますか？