This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pointer math vs named address spaces


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]