diff mbox

[UPC,15/22] RTL changes

Message ID 20151201060240.GA31274@intrepid.com
State New
Headers show

Commit Message

Gary Funck Dec. 1, 2015, 6:02 a.m. UTC
Background
----------

An overview email, describing the UPC-related changes is here:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00005.html

The GUPC branch is described here:
  http://gcc.gnu.org/projects/gupc.html

The UPC-related source code differences are summarized here:
  http://gccupc.org/gupc-changes

All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
bootstrapped; no test suite regressions were introduced,
relative to the GCC trunk.

If you are on the cc-list, your name was chosen either
because you are listed as a maintainer for the area that
applies to the patches described in this email, or you
were a frequent contributor of patches made to files listed
in this email.

In the change log entries included in each patch, the directory
containing the affected files is listed, followed by the files.
When the patches are applied, the change log entries will be
distributed to the appropriate ChangeLog file.

Overview
--------

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.

2015-11-30  Gary Funck  <gary@intrepid.com>

	gcc/
	* explow.c (promote_mode): For UPC pointer-to-shared values,
	return the mode of the UPC PTS representation type.

Comments

Richard Biener Dec. 2, 2015, 12:10 p.m. UTC | #1
On Tue, Dec 1, 2015 at 7:02 AM, Gary Funck <gary@intrepid.com> wrote:
>
> Background
> ----------
>
> An overview email, describing the UPC-related changes is here:
>   https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00005.html
>
> The GUPC branch is described here:
>   http://gcc.gnu.org/projects/gupc.html
>
> The UPC-related source code differences are summarized here:
>   http://gccupc.org/gupc-changes
>
> All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
> bootstrapped; no test suite regressions were introduced,
> relative to the GCC trunk.
>
> If you are on the cc-list, your name was chosen either
> because you are listed as a maintainer for the area that
> applies to the patches described in this email, or you
> were a frequent contributor of patches made to files listed
> in this email.
>
> In the change log entries included in each patch, the directory
> containing the affected files is listed, followed by the files.
> When the patches are applied, the change log entries will be
> distributed to the appropriate ChangeLog file.
>
> Overview
> --------
>
> 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?

Richard.

> 2015-11-30  Gary Funck  <gary@intrepid.com>
>
>         gcc/
>         * explow.c (promote_mode): For UPC pointer-to-shared values,
>         return the mode of the UPC PTS representation type.
>
> Index: gcc/explow.c
> ===================================================================
> --- gcc/explow.c        (.../trunk)     (revision 231059)
> +++ 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;
Jakub Jelinek Dec. 2, 2015, 12:24 p.m. UTC | #2
On Wed, Dec 02, 2015 at 01:10:44PM +0100, Richard Biener 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?

Then obviously the FE should lower the pointers to RECORD_TYPEs
then and present it to the middle-end as RECORD_TYPE.  For debug info,
the FEs lang flag or whatever on the side info should through some langhook
propagate the info that some var is a UPC pointer to shared into the debug
info, but the middle-end should treat it as any other RECORD_TYPE
afterwards.

> > 2015-11-30  Gary Funck  <gary@intrepid.com>
> >
> >         gcc/
> >         * explow.c (promote_mode): For UPC pointer-to-shared values,
> >         return the mode of the UPC PTS representation type.
> >
> > Index: gcc/explow.c
> > ===================================================================
> > --- gcc/explow.c        (.../trunk)     (revision 231059)
> > +++ 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;

	Jakub
Gary Funck Dec. 2, 2015, 11:34 p.m. UTC | #3
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
diff mbox

Patch

Index: gcc/explow.c
===================================================================
--- gcc/explow.c	(.../trunk)	(revision 231059)
+++ 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;