Re: [gfortran] Fix NULL reference types.

Re: [gfortran] Fix NULL reference types.

[Richard Kenner]

    Apparently the optimizers [could] assume that a reference type
    argument is never NULL.

Is this really correct?  If so, this has the potential of simplifying lots of
code in Ada if we use REFERENCE_TYPE for things that can never be null.

The CHAIN pointer of nested functions should also use it for the same reason.

Re: [gfortran] Fix NULL reference types.

[Nathan Sidwell]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

Richard Kenner wrote:
>     Apparently the optimizers [could] assume that a reference type
>     argument is never NULL.
> 
> Is this really correct?  If so, this has the potential of simplifying lots of
> code in Ada if we use REFERENCE_TYPE for things that can never be null.
I believe so, it is certainly true for C++.  I attach a documentation patch,
explaining such, ok?

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk


[-- Attachment #2: ref.patch --]
[-- Type: text/plain, Size: 2307 bytes --]

2004-08-18  Nathan Sidwell  <nathan@codesourcery.com>

	* tree.def (REFERENCE_TYPE): Clarify meaning.
	* doc/c-tree.texi (REFERENCE_TYPE): Likewise.

Index: tree.def
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.def,v
retrieving revision 1.97
diff -c -3 -p -r1.97 tree.def
*** tree.def	6 Aug 2004 10:40:30 -0000	1.97
--- tree.def	18 Aug 2004 13:42:50 -0000
*************** DEFTREECODE (POINTER_TYPE, "pointer_type
*** 186,193 ****
     that the offset is relative to.  */
  DEFTREECODE (OFFSET_TYPE, "offset_type", 't', 0)
  
! /* A reference is like a pointer except that it is coerced
!    automatically to the value it points to.  Used in C++.  */
  DEFTREECODE (REFERENCE_TYPE, "reference_type", 't', 0)
  
  /* METHOD_TYPE is the type of a function which takes an extra first
--- 186,194 ----
     that the offset is relative to.  */
  DEFTREECODE (OFFSET_TYPE, "offset_type", 't', 0)
  
! /* A reference is like a pointer except that it can never have a NULL
!    value.  Also front ends, such as C++, could automatically
!    dereference it to the referred-to object.  */
  DEFTREECODE (REFERENCE_TYPE, "reference_type", 't', 0)
  
  /* METHOD_TYPE is the type of a function which takes an extra first
Index: doc/c-tree.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/c-tree.texi,v
retrieving revision 1.61
diff -c -3 -p -r1.61 c-tree.texi
*** doc/c-tree.texi	20 Jul 2004 12:26:02 -0000	1.61
--- doc/c-tree.texi	18 Aug 2004 13:42:52 -0000
*************** For a pointer to data member type of the
*** 484,490 ****
  
  @item REFERENCE_TYPE
  Used to represent reference types.  The @code{TREE_TYPE} gives the type
! to which this type refers.
  
  @item FUNCTION_TYPE
  Used to represent the type of non-member functions and of static member
--- 484,493 ----
  
  @item REFERENCE_TYPE
  Used to represent reference types.  The @code{TREE_TYPE} gives the type
! to which this type refers.  A @code{REFERENCE_TYPE} is like a
! @code{POINTER_TYPE}, except that it can never have a NULL value.
! Frontends might automatically dereference an expression of
! @code{REFERENCE_TYPE} (g++ does this).
  
  @item FUNCTION_TYPE
  Used to represent the type of non-member functions and of static member

Re: [gfortran] Fix NULL reference types.

[Daniel Berlin]

On Aug 19, 2004, at 1:34 PM, Mark Mitchell wrote:

> Richard Kenner wrote:
>
>>    Kenner and I discussed this back in 1998:
>>
>>    http://gcc.gnu.org/ml/gcc-bugs/1998-07/msg00040.html
>>
>> I went back to that message.  You list four properties.  The latter 
>> two aren't
>> relevant for optimizers.
>>
>>  But the second is that it's never modified.
>> My feeling, though, is that REFERENCE_TYPE by itself shouldn't have 
>> that
>> property because we already have a way to represent something that's 
>> never
>> modified.
>>
>> That means that only difference is that REFERENCE_TYPE values cannot 
>> be
>> null while POINTER_TYPE values can be.  Does that seem right?
>>
> To me, yes.
>
> RTH's complaint about Fortran and debugging is interesting.  Although, 
> I don't think Fortran has a notion of "reference type" in the same way 
> that C++ does.  It might be that DWARF 2/3 already provides some way 
> of describing optional arguments that does not rely on their type 
> being REFERENCE_TYPE.  It might also be that we could adjust the 
> debug-generators to generate reference types even for optional 
> arguments.
>
> I suppose that we could provide the same information I wanted to 
> convey with REFERENCE_TYPE to the optimizer in some other way: a bit 
> on VAR_DECLs, PARM_DECLs, FIELD_DECLs, etc. that says "never NULL".
>
> I do think that we should find some way to give this information to 
> the optimizers.
>
When diego's assert_expr (range information) stuff goes in, you can 
always just add ASSERT_EXPRS at the beginning of the function for these 
variables, that says "!= 0"

The fact that the value is never 0 should be communicated to the 
optimizers the same way we will communicate other range information 
about variables.
--Dan
>

Re: [gfortran] Fix NULL reference types.

[Nathan Sidwell]

Richard Henderson wrote:
> On Wed, Aug 18, 2004 at 10:10:04AM -0400, Richard Kenner wrote:
> 
>>My question was whether the optimizers currently take advantage of that fact.

> Nope.  I, for one, wasn't aware of it.
Would this be a useful distinction to make then?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: [gfortran] Fix NULL reference types.

[Richard Henderson]

On Wed, Aug 18, 2004 at 10:10:04AM -0400, Richard Kenner wrote:
> My question was whether the optimizers currently take advantage of that fact.

Nope.  I, for one, wasn't aware of it.


r~

Re: [gfortran] Fix NULL reference types.

[Richard Kenner]

    I believe so, it is certainly true for C++.  I attach a documentation
    patch, explaining such, ok?

My question was whether the optimizers currently take advantage of that fact.