New flag: TREE_THIS_NOTRAP

New flag: TREE_THIS_NOTRAP

[Andrew Haley]

The idea here is to allow a language front end to tell the back end
what operands might generate traps.  Java already knows which memory
references cannot trap, and marking these MEM_NOTRAP_P reduces the
number of exception edges and improves scheduling.

There aren't any bits left in tree_common, so this patch (ab)uses
nothrow_flag.

I'm not convinced that this is the best solution, but I'm not sure how
else to do it.

Andrew.


2004-06-09  Andrew Haley  <aph@redhat.com>

	* tree.h (TREE_THIS_NOTRAP): New.
	* emit-rtl.c (set_mem_attributes_minus_bitpos): Set
	MEM_NOTRAP_P from TREE_THIS_NOTRAP.

Index: emit-rtl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/emit-rtl.c,v
retrieving revision 1.393
diff -p -2 -c -r1.393 emit-rtl.c
*** emit-rtl.c	28 May 2004 06:27:31 -0000	1.393
--- emit-rtl.c	9 Jun 2004 12:33:14 -0000
*************** set_mem_attributes_minus_bitpos (rtx ref
*** 1544,1547 ****
--- 1544,1548 ----
  	|| (! TYPE_P (t) && TREE_CONSTANT (t)));
    MEM_POINTER (ref) = POINTER_TYPE_P (type);
+   MEM_NOTRAP_P (ref) = TREE_THIS_NOTRAP (t);
  
    /* If we are making an object of this type, or if this is a DECL, we know
Index: tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.506
diff -p -2 -c -r1.506 tree.h
*** tree.h	7 Jun 2004 02:10:48 -0000	1.506
--- tree.h	9 Jun 2004 12:33:15 -0000
*************** struct tree_common GTY(())
*** 306,309 ****
--- 306,312 ----
  	   ..._TYPE
  
+        TREE_THIS_NOTRAP in
+            VAR_DECL, arithmetic expressions
+ 
     deprecated_flag:
  
*************** extern void tree_operand_check_failed (i
*** 789,792 ****
--- 792,801 ----
  #define TREE_THIS_VOLATILE(NODE) ((NODE)->common.volatile_flag)
  
+ /* Nonzero means this node will not trap.  In a MEM, means accessing
+    the memory at this node won't generate a trap.  However, this only
+    applies to an object when used appropriately: it doesn't mean that
+    writing a READONLY mem won't trap.  */
+ #define TREE_THIS_NOTRAP(NODE) ((NODE)->common.nothrow_flag)
+ 
  /* In a VAR_DECL, PARM_DECL or FIELD_DECL, or any kind of ..._REF node,
     nonzero means it may not be the lhs of an assignment.  */

Re: New flag: TREE_THIS_NOTRAP

[Richard Henderson]

On Wed, Jun 09, 2004 at 01:44:05PM +0100, Andrew Haley wrote:
> 	* tree.h (TREE_THIS_NOTRAP): New.
> 	* emit-rtl.c (set_mem_attributes_minus_bitpos): Set
> 	MEM_NOTRAP_P from TREE_THIS_NOTRAP.

Ok.


r~

Re: New flag: TREE_THIS_NOTRAP

[Richard Henderson]

On Wed, Jun 09, 2004 at 01:44:05PM +0100, Andrew Haley wrote:
> 	* tree.h (TREE_THIS_NOTRAP): New.

Oh, please also check for this in tree_could_trap_p.
And it probably only needs to apply to INDIRECT_REF;
VAR_DECLs and such already cannot trap.


r~

Re: New flag: TREE_THIS_NOTRAP

[Andrew Haley]

Richard Henderson writes:
 > On Wed, Jun 09, 2004 at 01:44:05PM +0100, Andrew Haley wrote:
 > > 	* tree.h (TREE_THIS_NOTRAP): New.
 > 
 > Oh, please also check for this in tree_could_trap_p.
 > And it probably only needs to apply to INDIRECT_REF;
 > VAR_DECLs and such already cannot trap.

Weak VAR_DECLs?  We have none in Java, but...

Andrew.

Re: New flag: TREE_THIS_NOTRAP

[Richard Henderson]

On Thu, Jun 10, 2004 at 10:22:25AM +0100, Andrew Haley wrote:
> Weak VAR_DECLs?  We have none in Java, but...

A good point.  Should perhaps update tree_could_trap_p
to take this into account.


r~

Re: New flag: TREE_THIS_NOTRAP

[Andrew Haley]

New, improved version.  I'm punting on the question of weak VAR_DECLS.

Andrew.


2004-06-11  Andrew Haley  <aph@redhat.com>

	* emit-rtl.c (set_mem_attributes_minus_bitpos): Check
	TREE_THIS_NOTRAP when setting MEM_NOTRAP_P.
	* tree-eh.c (tree_could_trap_p): Check TREE_THIS_NOTRAP.
	* tree.h (TREE_THIS_NOTRAP): New.

Index: emit-rtl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/emit-rtl.c,v
retrieving revision 1.393
diff -p -2 -c -r1.393 emit-rtl.c
*** emit-rtl.c	28 May 2004 06:27:31 -0000	1.393
--- emit-rtl.c	11 Jun 2004 16:25:20 -0000
*************** set_mem_attributes_minus_bitpos (rtx ref
*** 1544,1547 ****
--- 1544,1548 ----
  	|| (! TYPE_P (t) && TREE_CONSTANT (t)));
    MEM_POINTER (ref) = POINTER_TYPE_P (type);
+   MEM_NOTRAP_P (ref) = TREE_THIS_NOTRAP (t);
  
    /* If we are making an object of this type, or if this is a DECL, we know
Index: tree-eh.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-eh.c,v
retrieving revision 2.3
diff -p -2 -c -r2.3 tree-eh.c
*** tree-eh.c	30 May 2004 18:32:29 -0000	2.3
--- tree-eh.c	11 Jun 2004 16:25:20 -0000
*************** tree_could_trap_p (tree expr)
*** 1688,1694 ****
      case BIT_FIELD_REF:
        t = get_base_address (expr);
!       return !t || TREE_CODE (t) == INDIRECT_REF;
  
      case INDIRECT_REF:
      case TRUNC_DIV_EXPR:
      case CEIL_DIV_EXPR:
--- 1688,1699 ----
      case BIT_FIELD_REF:
        t = get_base_address (expr);
!       return !t || tree_could_trap_p (t);
  
      case INDIRECT_REF:
+       {
+ 	tree t = TREE_OPERAND (expr, 0);
+ 	return (TREE_THIS_NOTRAP (t) == false);
+       }
+ 
      case TRUNC_DIV_EXPR:
      case CEIL_DIV_EXPR:
Index: tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.506
diff -p -2 -c -r1.506 tree.h
*** tree.h	7 Jun 2004 02:10:48 -0000	1.506
--- tree.h	11 Jun 2004 16:25:22 -0000
*************** struct tree_common GTY(())
*** 306,309 ****
--- 306,312 ----
  	   ..._TYPE
  
+        TREE_THIS_NOTRAP in
+            arithmetic expressions
+ 
     deprecated_flag:
  
*************** extern void tree_operand_check_failed (i
*** 789,792 ****
--- 792,801 ----
  #define TREE_THIS_VOLATILE(NODE) ((NODE)->common.volatile_flag)
  
+ /* Nonzero means this node will not trap.  In an operand of pointer
+    type, means accessing the memory pointed to won't generate a trap.
+    However, this only applies to an object when used appropriately: it
+    doesn't mean that writing a READONLY mem won't trap.  */
+ #define TREE_THIS_NOTRAP(NODE) ((NODE)->common.nothrow_flag)
+ 
  /* In a VAR_DECL, PARM_DECL or FIELD_DECL, or any kind of ..._REF node,
     nonzero means it may not be the lhs of an assignment.  */

Re: New flag: TREE_THIS_NOTRAP

[Richard Henderson]

On Fri, Jun 11, 2004 at 05:41:31PM +0100, Andrew Haley wrote:
>       case INDIRECT_REF:
> +       {
> + 	tree t = TREE_OPERAND (expr, 0);
> + 	return (TREE_THIS_NOTRAP (t) == false);

So the NOTRAP bit is on the pointer and not the INDIRECT_REF?
This seems likely to get lost during gimplification, unless
you're taking extra special care...


r~

Re: New flag: TREE_THIS_NOTRAP

[Andrew Haley]

Richard Henderson writes:
 > On Fri, Jun 11, 2004 at 05:41:31PM +0100, Andrew Haley wrote:
 > >       case INDIRECT_REF:
 > > +       {
 > > + 	tree t = TREE_OPERAND (expr, 0);
 > > + 	return (TREE_THIS_NOTRAP (t) == false);
 > 
 > So the NOTRAP bit is on the pointer and not the INDIRECT_REF?

It has to be doesn't it?  The trapping in

   *exp

is a property of exp, not a property of *.  If someone attaches
another INDIRECT_REF to exp, it will not be marked as NOTRAP.

I could mark *both* exp and its INDIRECT_REF as notrap, I
guess.

 > This seems likely to get lost during gimplification, unless
 > you're taking extra special care...

Andrew.

Re: New flag: TREE_THIS_NOTRAP

[Richard Henderson]

On Fri, Jun 11, 2004 at 08:44:22PM +0100, Andrew Haley wrote:
> It has to be doesn't it?  The trapping in
> 
>    *exp
> 
> is a property of exp, not a property of *.  If someone attaches
> another INDIRECT_REF to exp, it will not be marked as NOTRAP.

Yes, but if someone copies exp to a compiler temporary,
we'll also lose the NOTRAP.  Something that is exceedingly
likely to occur when we go into and out of SSA form.

The INDIRECT_REF is more stable than the pointer in this.

Probably it would best be associated with the type of exp.
That's the property that should be reliably propagated 
during these transformations.  (There is a question of
whether tree_ssa_useless_type_conversion would discard
a type change between T* and T* nothrow, however.)


r~

Re: New flag: TREE_THIS_NOTRAP

[Jason Merrill]

On Fri, 11 Jun 2004 13:09:50 -0700, Richard Henderson <rth@redhat.com> wrote:

> Probably it would best be associated with the type of exp.
> That's the property that should be reliably propagated 
> during these transformations.  (There is a question of
> whether tree_ssa_useless_type_conversion would discard
> a type change between T* and T* nothrow, however.)

Yet another reason why tree_ssa_useless_type_conversion should go away in
favor of teaching optimizers to look back through the SSA chain.

Jason

Re: New flag: TREE_THIS_NOTRAP

[Andrew Haley]

Richard Henderson writes:
 > On Fri, Jun 11, 2004 at 08:44:22PM +0100, Andrew Haley wrote:
 > > It has to be doesn't it?  The trapping in
 > > 
 > >    *exp
 > > 
 > > is a property of exp, not a property of *.  If someone attaches
 > > another INDIRECT_REF to exp, it will not be marked as NOTRAP.
 > 
 > Yes, but if someone copies exp to a compiler temporary,
 > we'll also lose the NOTRAP.  Something that is exceedingly
 > likely to occur when we go into and out of SSA form.
 > 
 > The INDIRECT_REF is more stable than the pointer in this.

Right.

I've tested this a little bit, and in the cases I tried the NOTRAP is
propagated through the tree optimizers and all the way to assembly
code.

It might be worth doing this for ARRAY_REFs as well?

Andrew.


2004-06-16  Andrew Haley  <aph@redhat.com>

	* emit-rtl.c (set_mem_attributes_minus_bitpos): Check
	TREE_THIS_NOTRAP when setting MEM_NOTRAP_P.
	* tree-eh.c (tree_could_trap_p): Check TREE_THIS_NOTRAP.
	* tree.h (TREE_THIS_NOTRAP): New.

Index: emit-rtl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/emit-rtl.c,v
retrieving revision 1.394
diff -c -2 -p -w -r1.394 emit-rtl.c
*** emit-rtl.c	15 Jun 2004 18:02:16 -0000	1.394
--- emit-rtl.c	16 Jun 2004 15:22:47 -0000
*************** set_mem_attributes_minus_bitpos (rtx ref
*** 1544,1547 ****
--- 1544,1548 ----
  	|| (! TYPE_P (t) && TREE_CONSTANT (t)));
    MEM_POINTER (ref) = POINTER_TYPE_P (type);
+   MEM_NOTRAP_P (ref) = TREE_THIS_NOTRAP (t);
  
    /* If we are making an object of this type, or if this is a DECL, we know
Index: tree-eh.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-eh.c,v
retrieving revision 2.4
diff -c -2 -p -w -r2.4 tree-eh.c
*** tree-eh.c	11 Jun 2004 18:41:41 -0000	2.4
--- tree-eh.c	16 Jun 2004 15:22:48 -0000
*************** tree_could_trap_p (tree expr)
*** 1688,1694 ****
      case BIT_FIELD_REF:
        t = get_base_address (expr);
!       return !t || TREE_CODE (t) == INDIRECT_REF;
  
      case INDIRECT_REF:
      case TRUNC_DIV_EXPR:
      case CEIL_DIV_EXPR:
--- 1688,1696 ----
      case BIT_FIELD_REF:
        t = get_base_address (expr);
!       return !t || tree_could_trap_p (t);
  
      case INDIRECT_REF:
+       return (TREE_THIS_NOTRAP (expr) == false);
+ 
      case TRUNC_DIV_EXPR:
      case CEIL_DIV_EXPR:
Index: tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.515
diff -c -2 -p -w -r1.515 tree.h
*** tree.h	16 Jun 2004 05:09:40 -0000	1.515
--- tree.h	16 Jun 2004 15:22:50 -0000
*************** struct tree_common GTY(())
*** 306,309 ****
--- 306,312 ----
  	   ..._TYPE
  
+        TREE_THIS_NOTRAP in
+           INDIRECT_REF
+ 
     deprecated_flag:
  
*************** extern void tree_operand_check_failed (i
*** 762,765 ****
--- 765,774 ----
  #define TREE_THIS_VOLATILE(NODE) ((NODE)->common.volatile_flag)
  
+ /* Nonzero means this node will not trap.  In an operand of pointer
+    type, means accessing the memory pointed to won't generate a trap.
+    However, this only applies to an object when used appropriately: it
+    doesn't mean that writing a READONLY mem won't trap.  */
+ #define TREE_THIS_NOTRAP(NODE) ((NODE)->common.nothrow_flag)
+ 
  /* In a VAR_DECL, PARM_DECL or FIELD_DECL, or any kind of ..._REF node,
     nonzero means it may not be the lhs of an assignment.  */

Re: New flag: TREE_THIS_NOTRAP

[Andrew Haley]

Oh hell, I forgot to change the comment.

Index: tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.515
diff -c -2 -p -w -r1.515 tree.h
*** tree.h	16 Jun 2004 05:09:40 -0000	1.515
--- tree.h	16 Jun 2004 15:36:16 -0000
*************** struct tree_common GTY(())
*** 306,309 ****
--- 306,312 ----
  	   ..._TYPE
  
+        TREE_THIS_NOTRAP in
+           INDIRECT_REF
+ 
     deprecated_flag:
  
*************** extern void tree_operand_check_failed (i
*** 762,765 ****
--- 765,774 ----
  #define TREE_THIS_VOLATILE(NODE) ((NODE)->common.volatile_flag)
  
+ /* Nonzero means this node will not trap.  In an INDIRECT_REF, means
+    accessing the memory pointed to won't generate a trap.  However,
+    this only applies to an object when used appropriately: it doesn't
+    mean that writing a READONLY mem won't trap.  */
+ #define TREE_THIS_NOTRAP(NODE) ((NODE)->common.nothrow_flag)
+ 
  /* In a VAR_DECL, PARM_DECL or FIELD_DECL, or any kind of ..._REF node,

Re: New flag: TREE_THIS_NOTRAP

[Frank Ch. Eigler]

aph wrote:

> [...]
> + /* Nonzero means this node will not trap.  In an INDIRECT_REF, means
> +    accessing the memory pointed to won't generate a trap.  However,
> +    this only applies to an object when used appropriately: it doesn't
> +    mean that writing a READONLY mem won't trap.  */
> [...]

This flag could be useful for mudflap's purposes also, in that the
passes could treat incoming INDIRECT_REFs marked with this flag as
"not to be instrumented".  However, I am a little confused about the
exact meaning of "used appropriately" above - it sounds a little less
restricted than mudflap's notions of pointer checking.

- FChE

Re: New flag: TREE_THIS_NOTRAP

[Andrew Haley]

Frank Ch. Eigler writes:
 > 
 > aph wrote:
 > 
 > > [...]
 > > + /* Nonzero means this node will not trap.  In an INDIRECT_REF, means
 > > +    accessing the memory pointed to won't generate a trap.  However,
 > > +    this only applies to an object when used appropriately: it doesn't
 > > +    mean that writing a READONLY mem won't trap.  */
 > > [...]
 > 
 > This flag could be useful for mudflap's purposes also, in that the
 > passes could treat incoming INDIRECT_REFs marked with this flag as
 > "not to be instrumented".  However, I am a little confused about the
 > exact meaning of "used appropriately" above - it sounds a little less
 > restricted than mudflap's notions of pointer checking.

It just means that this flag doesn't override other meanings, such as
writing to a read-only mem or reading from a write-only or
execute-only mem.

Andrew.

Re: New flag: TREE_THIS_NOTRAP

[Richard Henderson]

On Wed, Jun 16, 2004 at 04:33:17PM +0100, Andrew Haley wrote:
> It might be worth doing this for ARRAY_REFs as well?

I think with arrays we're under the "used appropriately" clause.
If you really do have an array, all indicies won't trap.  How do
you get hold of the array?  It's either a VAR_DECL, or it's a
pointer to an array that you're dereferencing (i.e. (*a)[i]).

> 	* emit-rtl.c (set_mem_attributes_minus_bitpos): Check
> 	TREE_THIS_NOTRAP when setting MEM_NOTRAP_P.
> 	* tree-eh.c (tree_could_trap_p): Check TREE_THIS_NOTRAP.
> 	* tree.h (TREE_THIS_NOTRAP): New.

Ok.


r~

Re: New flag: TREE_THIS_NOTRAP

[Tom Tromey]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

rth> So the NOTRAP bit is on the pointer and not the INDIRECT_REF?

Andrew> It has to be doesn't it?  The trapping in
Andrew>    *exp
Andrew> is a property of exp, not a property of *.

Suppose for example we have a sequence of field assignments via a
local variable:

   point *var = ...;
   var->x = 1;
   var->y = 1;

The first `*var' might trap, but the second one can't.
But in both cases wouldn't this be INDIRECT_REF<VAR_DECL> -- with the
same argument?  So if we set TREE_THIS_NOTRAP, we would end up with
an incorrect answer.

Am I misunderstanding?

Tom

Re: New flag: TREE_THIS_NOTRAP

[Andrew Haley]

Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > rth> So the NOTRAP bit is on the pointer and not the INDIRECT_REF?
 > 
 > Andrew> It has to be doesn't it?  The trapping in
 > Andrew>    *exp
 > Andrew> is a property of exp, not a property of *.
 > 
 > Suppose for example we have a sequence of field assignments via a
 > local variable:
 > 
 >    point *var = ...;
 >    var->x = 1;
 >    var->y = 1;
 > 
 > The first `*var' might trap, but the second one can't.

I think that's true for Java, where we're not allowed to re-order
stores.

 > But in both cases wouldn't this be INDIRECT_REF<VAR_DECL> -- with the
 > same argument?

Yes.  But I've already been persuaded to attach the NOTRAP bit to the
INDIRECT_REF anyway.  This should probably become a type attribute, so
the above could be

    point *var = ...;
    var->x = 1;
    ((notrap point*)var)->y = 1;

I'm a bit lary of generating new types, though, because I want to
avoid a memory explosion.  It's perhaps worth experimenting with.
 
Andrew.