Re: pointer math vs named address spaces

[Richard Henderson <rth at redhat dot com>]

On 12/10/2014 05:36 AM, Richard Biener wrote:
> 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?

That was supposed to be answered in the next paragraph.  ;-)

> 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).

Ug.  That's true.  I hadn't even started to think what the implications of
changing the type might be.  Oh well.


r~