Re: pointer math vs named address spaces

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

On Wed, Dec 10, 2014 at 2:24 AM, Richard Henderson <rth@redhat.com> wrote:
> On 12/04/2014 01:54 AM, Richard Biener wrote:
>> Apart from what Joseph already said using 'sizetype' in the middle-end
>> for sizes and offsets is really really deep-rooted into the compiler.
>> What you see above is one aspect - POINTER_PLUS_EXPR offsets
>> are forced to have sizetype type.  But you'd also see it in the inability
>> to create larger than sizetype objects (DECL_SIZE_UNITs type).
>>
>> So for the middle-end part I'd suggest you make sure that sizetype
>> covers the largest pointer-mode precision your target offers.  That of course
>> doesn't fix what Joseph pointed out - that the user will still run into issues
>> when writing C programs or when using the C runtime (I suppose TR 18037
>> doesn't specify alternate memcpy for different address spaces?)
>
> I'd prefer it if the middle-end were more flexible about what types it allows
> for the offset of POINTER_PLUS_EXPR.  E.g. any integer type of an appropriate mode.

What is an appropriate mode?  But yes, in general I agree that having
the offset type of POINTER_PLUS_EXPR fixed to sizetype (or any
compatible type) is technically not necessary - though changing that
requires touching a _lot_ of code (everyone using size_{un,bin}op
on it).  I've tried the more simplistic idea of allowing ssizetype as well
and failed due to all the fallout ... (that was ~2 years ago).

> I'd expect the right answer is to match targetm.addr_space.address_mode rather
> than .pointer_mode, so that any extension, if necessary, is already exposed to
> the optimizers.  But I suppose it's also possible that might pessimize things
> for these weird targets...

Well.  On the tree level we can certainly say that POINTER_PLUS_EXPR
is simply first converting the offset to an appropriate type and then performing
the addition.  The choice of that type is then defered to the RTL expander.

For C code doing ptr[i] you still have the issue that sizeof (*ptr) * i needs
to be carried out in a large enough type (or use a widening multiplication
or do not lower to pointer arithmetic).  Currently the C frontend chooses
a type with the precision of sizetype for this.

Richard.

>
> r~