A good optimizing compiler tries hard to preserve restrict aliasing of
a callee function in its inline instance, and this is usually a hard
problem because the use of restrict qualified pointers are now mixed
with the caller context. In many cases, the compiler may choose not
to inline the function.
The above does apply to your case. Ininling of store_int into foo is
irrelevant to the aliasing attribute here.
David
On Fri, Nov 19, 2010 at 9:12 AM, Bingfeng Mei <b...@broadcom.com> wrote:
> Hello,
> I have been struggling with GCC's restrict implementation. One question is:
> should "restrictness" be preserved over function inlining? For example, in
> the following code:
>
>
> static int store_int (int *a, int data)
> {
> *a = data;
> }
>
>
> void foo (int * __restrict a, int *__restrict b)
> {
> int data;
> data = *b;
> store_int (a, b);
> data = *(b+1);
> store_int (a, b + 1);
> }
>
> Currently, trunk GCC generates following code (compile with
> -fschedule-insns -O2). Obviously, restrict is effective here
> even with inlining
>
> foo:
> .LFB1:
> movl (%rsi), %edx
> movl 4(%rsi), %eax
> movl %edx, (%rdi)
> movl %eax, 4(%rdi)
> ret
>
> I am not very good at reading standard text. Does this
> behaviour conform to standard?
>
> Additionally, should "restrictness" be preserved over casting?
> If I modify store_int to as follows (store 64-bit now).
>
> static int store_int (int *a, int data)
> {
> *(long long *)a = data;
> }
>
> GCC generates code that "restrict" is still effective.
> foo:
> .LFB1:
> movslq (%rsi), %rdx
> movslq 4(%rsi), %rax
> movq %rdx, (%rdi)
> movq %rax, 4(%rdi)
> ret
>
> Does this conform to standard?
>
> Cheers,
> Bingfeng
>
>
