Re: [PATCH PING 2/5] Named address spaces: support multiple pointer modes

[Richard Guenther <richard dot guenther at gmail dot com>]

On Mon, Sep 21, 2009 at 3:41 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> Richard Guenther wrote:
>
>> + ? ? ?/* As we do not know which address space the pointer is
>> refering to, we can
>> + ? ? ? ?handle this only if the target does not support different pointer =
>> or
>> + ? ? ? ?address modes depending on the address space. ?*/
>> + ? ? ?if (targetm.addr_space.address_mode !=3D default_addr_space_address_=
>> mode
>> + ? ? ? ? ?|| targetm.addr_space.pointer_mode !=3D
>> default_addr_space_pointer_mode)
>>
>> I think these changes are ugly. ?Please at least add a macro
>> TARGET_SUPPORTS_ADDR_SPACE_P that expands to this test.
>
> OK, I've checked the patch below into the named-addr-spaces-branch.

Thanks.

>> It seems that really you should test if the current TU uses address
>> space qualified types, no?
>
> Well, that could be an optimization, I guess. ?(A more specific one
> would be to actually encode the address space pointed to for registers
> marked as REG_POINTER. ?Then we could just use the proper mode ...)
>
> I'm not sure this is worth the effort at this point, as all these
> checks make a difference only on targets that simultaneously support
> named address spaces and pointer mode != address mode scenarios. ?We
> currently do not have any such targets, the check is just a fail-safe ...
>
>> Why do we need different modes for address spaces at all? ?As I don't
>> really understand the issues here I don't feel qualified to review the
>> patch. ?Sorry. ?Why would a single mode for all address spaces be enough?
>> Isn't everything lowered during expansion, maybe simply using UNSPECs?
>
> Well, we (may) need different modes for pointers to different address
> spaces because those pointers may be differently sized. ?For example,
> on the SPU (when using the -mea64 mode), generic pointers are 32-bit
> values (or more precisely, 18-bit values stored in a 32-bit field)
> refering to the SPU local store, while __ea pointers are 64-bit values
> refering to the PowerPC process address space. ?So you have
> ?sizeof (void *) == 4
> ?sizeof (__ea void *) == 8
>
> Other potential uses of the named address space infrastructure may
> likewise require different pointer sizes, e.g. you could implement a
> 16-bit Intel mode with near / far pointers (2 vs. 4 bytes) and so on ...
>
> I don't quite see where expansion comes in here; the different pointer
> sizes are even visible on the language level. ?In any case, even while
> the current SPU patch does indeed lower all non-generic address space
> accesses during expansion (because we use a software-emulated cache),
> other implementations may well have actual instructions to access
> non-generic address spaces, so those will need to be represented
> throughout the RTL stages.
>
> (Actually, even on the SPU, operations on __ea pointers *except*
> dereference ?-- copying a pointer value, pointer arithmetic etc. --
> *is* expanded into RTL and has to use the proper mode throughout
> the RTL stages ...)

With expand and UNSPECs I was thinking of just using integral
modes for the address-space qualified pointers and relying on
the UNSPECs doing the right things with them.  I agree that they
might have different sizes, but do we need different _pointer_ modes
for them?  I guess not necessarily...

Well - defering to others here ;)

Thanks,
Richard.