On 12/10/2014 05:36 AM, Richard Biener wrote:
> On Wed, Dec 10, 2014 at 2:24 AM, Richard Henderson <r...@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~
