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? 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~