This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [UPC 15/22] RTL changes
- From: Gary Funck <gary at intrepid dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Gcc Patches <gcc-patches at gcc dot gnu dot org>, Andrew MacLeod <amacleod at redhat dot com>, Eric Botcazou <ebotcazou at libertysurf dot fr>, Steven Bosscher <steven at gcc dot gnu dot org>, Nenad Vukicevic <nenad at intrepid dot com>
- Date: Wed, 2 Dec 2015 15:34:35 -0800
- Subject: Re: [UPC 15/22] RTL changes
- Authentication-results: sourceware.org; auth=none
- References: <20151201060240 dot GA31274 at intrepid dot com> <CAFiYyc2BxBgL3Ujca5hAds+20QcjEYNhT4LiJkgGNjQFGdJLFQ at mail dot gmail dot com>
On 12/02/15 13:10:44, Richard Guenther wrote:
> On Tue, Dec 1, 2015 at 7:02 AM, Gary Funck <gary@intrepid.com> wrote:
> > UPC pointers-to-shared have an internal representation which is
> > defined as a 'struct' with three fields. Special logic is
> > needed in promote_mode() to handle this case.
>
> Errr - but how are 'struct's ever REFERENCE_TYPE or POINTER_TYPE?
UPC pointers-to-shared types are pointer types, but they typically
have a mode that is 2x the size of the normal pointer mode.
Currently, 'upc_pts_type_node' is a global tree mode that
describes the internal representation of a UPC pointer-to-shared.
The code shown below takes the mode of 'upc_pts_type_node'
(TIMode, typically on 64 bit targets) and returns that.
As noted in an earlier reply, this mode could be saved in
a global somewhere (similar to pointer_mode) which could
be used to avoid the reference to 'upc_pts_type_node' below.
> > +++ gcc/explow.c (.../branches/gupc) (revision 231080)
> > @@ -794,6 +794,8 @@ promote_mode (const_tree type ATTRIBUTE_
> > case REFERENCE_TYPE:
> > case POINTER_TYPE:
> > *punsignedp = POINTERS_EXTEND_UNSIGNED;
> > + if (SHARED_TYPE_P (TREE_TYPE (type)))
> > + return TYPE_MODE (upc_pts_type_node);
> > return targetm.addr_space.address_mode
> > (TYPE_ADDR_SPACE (TREE_TYPE (type)));
> > break;
Asked in previous email: Can an address space be used
for UPC pointers-to-shared? Yes, if TIMode were allowed,
for example (on 64-bit targets), and that was the mode
associated with th special UPC reserved address space number,
it would take care of returning the proper mode for
UPC pointers-to-shared types.
Address spaces are insufficient however to handle the
situations where the semantics of pointer arithmetic for UPC
pointers-to-shared differs from those of regular "C" pointers,
or for conversions, and situations where optimizations of operations
involving "C" pointers do not apply to "UPC" shared pointers.
So, we can't just dedicate an address space for UPC pointers-to-shared
and be done with it.
thanks,
- Gary