Re: Different multiply operator for pointers and integers

[Laura Tosoratto <Laura dot Tosoratto at roma1 dot infn dot it>]

Thanks for your answers. I'm aware that I could be more precise in the 
description, so I will try to clarify some points:

Richard Henderson wrote:

> On Thu, Dec 16, 2004 at 06:29:22PM -0000, Dave Korn wrote:
>  
>
> >  Sorry, I don't quite get the wording here; I can't tell exactly what is the
> > referent of "that" in the above sentence.  I'm not sure if you mean
> >
> > 1) If it is true that registers that hold pointers can only be used
> > for pointers and not integers, there's absolutely....
> >    
>
> This one.
>
>  
1)Registers that _must_ hold addresses (pointers) _can_ hold integers as 
well.
2)Addresses are roughly represented as 32 LSB for local to node memory 
addresses and 32 MSB
for addressing remote nodes on the machine.
3)When an address calculation is performed  (i.e.  for a[i])  I want to 
use the mult_a operator (at RTL level)
instead of the mult_i:
@a[i] = &a + i mult_a sizeof(a[i])
because I want to leave unchanged the upper 32 bits of the address (the 
remote part).
A typical situation is:
b = a[i+X_PLUS]
that means that I want to read variable a[i] on the remote node at 
coordinates x+1 from the local node (machine has SIMD architecture)
and store it in the local variable b. X_PLUS is a pure remote address 
(its lower 32 bits are zero).

I do not need to make explicit arithmetic multiplications on pointers, 
but  looking
into expr.c I see that ARRAY_REF tree nodes generate ptr_mode 
expressions for the
address calculation.

> >  Hmm, but wouldn't the potential workaround of defining Pmode to some mode
> > (other than SImode) that is not used by the machine ...
> >    
>
> No.  The problems start in the front end.
>
>
>  
So you would suggest to change the front-end, e.g. introducing a new 
tree operator and modifing the parser?
I wanted to avoid this and try to make a porting as "standard" as possible.

> r~
>
>  
Thanks,

Laura