On Wed, Jun 3, 2009 at 1:02 PM, Bingfeng Mei <b...@broadcom.com> wrote:
> Richard,
> Yes, my original code does have restrict qualified decl:
>
> void foo(int byte, char *a, char *b){
> int * restrict dest = (int *)a;
> int * restrict src = (int *)b;
>
> for(int i = 0; i < byte/8; i++){
> *dest++ = *src++;
> }
> }
>
>
> The code I shown is produced by tree level compilation.
>
> *(int * restrict) (D.1934 + 4) = *(int * restrict) (D.1936 + 4);
> *(int * restrict) (D.1934 + 8) = *(int * restrict) (D.1936 + 8);
> *(int * restrict) (D.1934 + 12) = *(int * restrict) (D.1936 + 12);
> *(int * restrict) (D.1934 + 16) = *(int * restrict) (D.1936 + 16);
> *(int * restrict) (D.1934 + 20) = *(int * restrict) (D.1936 + 20);
> *(int * restrict) (D.1934 + 24) = *(int * restrict) (D.1936 + 24);
> *(int * restrict) (D.1934 + 28) = *(int * restrict) (D.1936 + 28);
> *(int * restrict) (D.1934 + 32) = *(int * restrict) (D.1936 + 32);
> *(int * restrict) (D.1934 + 36) = *(int * restrict) (D.1936 + 36);
> *(int * restrict) (D.1934 + 40) = *(int * restrict) (D.1936 + 40);
> *(int * restrict) (D.1934 + 44) = *(int * restrict) (D.1936 + 44);
> *(int * restrict) (D.1934 + 48) = *(int * restrict) (D.1936 + 48);
> *(int * restrict) (D.1934 + 52) = *(int * restrict) (D.1936 + 52);
> *(int * restrict) (D.1934 + 56) = *(int * restrict) (D.1936 + 56);
> *(int * restrict) (D.1934 + 60) = *(int * restrict) (D.1936 + 60);
>
> If we agree these tree statements still preserve the meaning of restrict,
> it should be RTL expansion going wrong. Am I right?
No, it is TER that removes the temporary that is required to make
restrict work. Try -fno-tree-ter or fixing TER to not TER
to-restrict-pointer conversions.
Richard.
>
> - Bingfeng
>
>
>> -----Original Message-----
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: 03 June 2009 11:54
>> To: Bingfeng Mei
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: Restrict keyword doesn't work correctly in GCC 4.4
>>
>> On Wed, Jun 3, 2009 at 12:41 PM, Bingfeng Mei
>> <b...@broadcom.com> wrote:
>> > Hello,
>> > I noticed that the restrict doesn't work fully on 4.4.0
>> (used to work on
>> > our port based on 4.3 branch). The problem is that tree
>> optimizer can do a
>> > lot of optimization regarding pointer, e.g., at -O3. The
>> alias set property
>> > is not propagated accordingly.
>> >
>> > Is the following RTL expansion correct? Both read and write
>> address are
>> > converted to a restrict pointer, but the both mem rtx have
>> the same alias set (2).
>> >
>> > ;; *(int * restrict) (D.1768 + 4) = *(int * restrict) (D.1770 + 4);
>>
>> restrict only works if there is a restrict qualified pointer decl in
>> your source.
>>
>> I will re-implement restrict support completely for 4.5.
>>
>> You can try the attached hack which might help (but also cause
>> weird effects ...).
>>
>> Richard.
>>
>> > (insn 56 55 57 tst.c:7 (set (reg:SI 124)
>> > (mem:SI (plus:SI (reg:SI 103 [ D.1770 ])
>> > (const_int 4 [0x4])) [2 S4 A32])) -1 (nil))
>> >
>> > (insn 57 56 0 tst.c:7 (set (mem:SI (plus:SI (reg:SI 104 [ D.1768 ])
>> > (const_int 4 [0x4])) [2 S4 A32])
>> > (reg:SI 124)) -1 (nil))
>> >
>> >
>> > The alias set property is copied from tree node:
>> > <indirect_ref 0xf7f09d40
>> > type <integer_type 0xf7f122f4 int sizes-gimplified public SI
>> > size <integer_cst 0xf7f0f9d8 constant 32>
>> > unit size <integer_cst 0xf7f0f7c4 constant 4>
>> > align 32 symtab 0 alias set 2 canonical type
>> 0xf7f122f4 precision 32 min <integer_cst 0xf7f0f984
>> -2147483648> max <integer_cst 0xf7f0f9a0 2147483647>
>> > pointer_to_this <pointer_type 0xf7f18798>>
>> >
>> > arg 0 <nop_expr 0xf7fc7400
>> > type <pointer_type 0xf7fa6870 type <integer_type
>> 0xf7f122f4 int>
>> > sizes-gimplified public unsigned restrict SI
>> size <integer_cst 0xf7f0f9d8 32> unit size <integer_cst 0xf7f0f7c4 4>
>> > align 32 symtab 0 alias set -1 canonical type 0xf7fa6870>
>> >
>> > arg 0 <plus_expr 0xf7fc95e8 type <integer_type
>> 0xf7f12438 long unsigned int>
>> > arg 0 <var_decl 0xf7fc4a6c D.1768>
>> > arg 1 <integer_cst 0xf7fb7bec constant 4>
>> > tst.c:7:5>
>> > tst.c:7:5>
>> > tst.c:7:5>
>> >
>> > Is the RTL expansion wrong or the orginal tree node is
>> constructed incorrectly?
>> >
>> > Thanks,
>> > Bingfeng Mei
>> >
>> > Broadcom UK
>> >
>>
>
