Why convert to pointer type before added to a pointer

Why convert to pointer type before added to a pointer

[Jie Zhang]

This simple code

void
foo (int* a, int n)
{
   a[n] = 1;
}

is transformed into

foo (a, n)
{
   unsigned int n.0;
   unsigned int T.1;
   int * T.2;
   int * T.3;

   n.0 = (unsigned int)n;
   T.1 = n.0 * 4;
   T.2 = (int *)T.1;      <== Why this converting
   T.3 = T.2 + a;
   *T.3 = 1;
}

after the genericizing. Thanks.

cheers
-- 
Jie

RE: Why convert to pointer type before added to a pointer

[Rupert Wood]

Jie Zhang wrote: 

Well (to my untrained eye) this looks like:

>    n.0 = (unsigned int)n;
>    T.1 = n.0 * 4;

Compute the byte-offset for the index as an unsigned integer.

>    T.2 = (int *)T.1;      <== Why this converting

This isn't really an int* - it's more logically ptrdiff_t. It's the array
offset in bytes; it's going to be added to a, which is int*, so I guess
GIMPLE wants the offset as an int* too and requires a new temporary for the
conversion.

>    T.3 = T.2 + a;
>    *T.3 = 1;

Finish computing &(a[n]) in T.3 and then set the value.


Please forgive my ignorance, but -

Performing the index computation as unsigned looks wrong to me. I suspect
this because sizeof(int) is unsigned, but isn't a[-1] acceptable? I can't
navigate the C standard well enough to see what it says.

Rup.

Re: Why convert to pointer type before added to a pointer

[Jeffrey A Law]

On Mon, 2004-08-16 at 04:03, Jie Zhang wrote:
> This simple code
> 
> void
> foo (int* a, int n)
> {
>    a[n] = 1;
> }
> 
> is transformed into
> 
> foo (a, n)
> {
>    unsigned int n.0;
>    unsigned int T.1;
>    int * T.2;
>    int * T.3;
> 
>    n.0 = (unsigned int)n;
>    T.1 = n.0 * 4;
>    T.2 = (int *)T.1;      <== Why this converting
>    T.3 = T.2 + a;
>    *T.3 = 1;
> }
> 
> after the genericizing. Thanks.
It's an unfortunate aspect of the type system we have -- basically
both operands of a binary operator need to have compatible types.

I spent some time investigating ways to fix this in the context of
solving some long standing problems with the PA, IA-64 and mn10300
ports.

The first approach is to have a separate set of operators such as
PLUS_PTR_EXPR, MINUS_PTR_EXPR which do not require their operands
to be the same type.  That's ugly simply because everywhere you 
generate or test for PLUS_EXPR or MINUS_EXPR you have to to examine
the types to determine instead you should be using PLUS_PTR_EXPR
or MINUS_PTR_EXPR.

The other approach is to relax the type system.  That's bad from the
standpoint of being able to perform internal consistency checking.

Right now we just convert the index to a pointer type and hope
everything works out in the end.  That's not particularly good
either and has led to a little hack in how we compute REG_POINTER_FLAG
when converting from trees into RTL.

jeff

Re: Why convert to pointer type before added to a pointer

[Jie Zhang]

Hi Jeff,

> 
> It's an unfortunate aspect of the type system we have -- basically
> both operands of a binary operator need to have compatible types.
>

Why does our type system behave like this? Could you or somebody else 
give me an outline of the type system?

> 
> The first approach is to have a separate set of operators such as
> PLUS_PTR_EXPR, MINUS_PTR_EXPR which do not require their operands
> to be the same type.  That's ugly simply because everywhere you 
> generate or test for PLUS_EXPR or MINUS_EXPR you have to to examine
> the types to determine instead you should be using PLUS_PTR_EXPR
> or MINUS_PTR_EXPR.
> 
> The other approach is to relax the type system.  That's bad from the
> standpoint of being able to perform internal consistency checking.
> 
I think the latter one is better. I would even say it's to correct the 
type system. In the C99 standard, it reads

   6.5.6.2
   For addition, either both operands shall have arithmetic type,
   or one operand shall be a pointer to an object type and the
   other shall have integer type.

Adding two pointers is not allowed by the constraints. But I may miss 
something, since I now have little knowledge on our type system.


cheers
-- 
Jie

Re: Why convert to pointer type before added to a pointer

[Jie Zhang]

Hi Rup,

>>   n.0 = (unsigned int)n;
>>   T.1 = n.0 * 4;
> 
> 
> Compute the byte-offset for the index as an unsigned integer.
> 
> 
> Performing the index computation as unsigned looks wrong to me. I suspect
> this because sizeof(int) is unsigned, but isn't a[-1] acceptable? I can't
> navigate the C standard well enough to see what it says.
> 

I also think we should not compute the index as unsigned. I think C99 
accepts a[-1].


cheers
-- 
Jie

Re: Why convert to pointer type before added to a pointer

[Falk Hueffner]

Jie Zhang <zhangjie@magima.com.cn> writes:

>>>   n.0 = (unsigned int)n;
>>>   T.1 = n.0 * 4;
>> Compute the byte-offset for the index as an unsigned integer.
>> Performing the index computation as unsigned looks wrong to me. I
>> suspect
>> this because sizeof(int) is unsigned, but isn't a[-1] acceptable? I can't
>> navigate the C standard well enough to see what it says.
>>
>
> I also think we should not compute the index as unsigned. I think C99
> accepts a[-1].

Well, it doesn't matter as long as it's done at the same width as that
of pointers.

-- 
	Falk

Re: Why convert to pointer type before added to a pointer

[Jie Zhang]

Falk Hueffner wrote:
> 
> Well, it doesn't matter as long as it's done at the same width as that
> of pointers.
> 
Then, why do we bother to cast index integer to unsigned? It does not 
conform to the standard, and maybe it will incur bugs in future.


cheers
-- 
Jie

Re: Why convert to pointer type before added to a pointer

[Jie Zhang]

Jeffrey A Law wrote:
> The other approach is to relax the type system.  That's bad from the
> standpoint of being able to perform internal consistency checking.
> 
I try this patch, bootstraped and tested for gcc. It failed 
gcc.dg/tree-ssa/20030815-1.c. But I think it is not a regression. This 
test check there is one and only one (struct rtx_def * *) case. Even 
this one is eliminated with this patch. I have not touched the front end 
of C++, Fortran or Java. This patch is an initial trial, but I think it 
show that this idea works. How will this affect gcc performing internal 
consistency checking?


cheers
-- 
Jie

--- c-common.c  2004-08-15 23:44:49.000000000 +0800
+++ c-common.c.new      2004-08-20 10:38:26.952057800 +0800
@@ -2282,9 +2282,8 @@ pointer_int_sum (enum tree_code resultco
       Do this multiplication as signed, then convert to the appropriate
       pointer type (actually unsigned integral).  */

-  intop = convert (result_type,
-                  build_binary_op (MULT_EXPR, intop,
-                                   convert (TREE_TYPE (intop), 
size_exp), 1));
+  intop = build_binary_op (MULT_EXPR, intop,
+                          convert (TREE_TYPE (intop), size_exp), 1));

    /* Create the sum or difference.  */
    return fold (build2 (resultcode, result_type, ptrop, intop));