This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: pointer math vs named address spaces
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, DJ Delorie <dj at redhat dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 09 Dec 2014 17:24:38 -0800
- Subject: Re: pointer math vs named address spaces
- Authentication-results: sourceware.org; auth=none
- References: <201412032234 dot sB3MYEmp030041 at greed dot delorie dot com> <CAFiYyc3fWFOdX=K63DaeSp5QmmQPyck7ib9Gr7V+d84VAxie2g at mail dot gmail dot com>
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.
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...
r~