[patch] handle restrict at tree level

Dan Nicolaescu dann@godzilla.ics.uci.edu
Thu Jul 1 23:48:00 GMT 2004


Given: 

extern void link_error (void);

void bar0 (int * __restrict__ arr1, int * __restrict__ arr2)
{
  arr1[0] = 1;
  arr2[0] = 1;
  if (arr1[0] != 1)
    link_error ();
}

arr1 and arr2 should not alias, hence the "if" should be eliminated. 
The RTL optimizers can deal with this, but not the tree optimizers. 

But the tree optimizers can deal with the following code: 

extern int foo (int * , int *);
void bar1 (void)
{
  int * arr1 = malloc (12);
  int * arr2 = malloc (12);
  arr1[0] = 1;
  arr2[0] = 1;
  if (arr1[0] != 1)
    link_error ();
  foo (arr1, arr2);
}

the arr[12] pointers have very similar properties in the bar0 and bar1
functions, so they could be treated the same way.  Would this be correct? 

2004-07-01  Dan Nicolaescu  <dann@ics.uci.edu>
        PR14187
	* tree-ssa-alias.c (add_pointed_to_expr): Handle restricted
          pointers the same way as malloc results.


*** tree-ssa-alias.c.~2.8.~	Mon Jun 28 11:58:05 2004
--- tree-ssa-alias.c	Thu Jul  1 16:24:51 2004
***************
*** 1570,1579 ****
  
    pi = get_ptr_info (ptr);
  
!   /* If VALUE is the result of a malloc-like call, then the area pointed to
!      PTR is guaranteed to not alias with anything else.  */
!   if (TREE_CODE (value) == CALL_EXPR
        && (call_expr_flags (value) & (ECF_MALLOC | ECF_MAY_BE_ALLOCA)))
      pi->pt_malloc = 1;
    else
      pi->pt_anything = 1;
--- 1570,1581 ----
  
    pi = get_ptr_info (ptr);
  
!   /* If VALUE is the result of a malloc-like call, then the area
!      pointed to PTR is guaranteed to not alias with anything else. The
!      same is true for restricted pointers, treat them the same way.  */
!   if ((TREE_CODE (value) == CALL_EXPR
        && (call_expr_flags (value) & (ECF_MALLOC | ECF_MAY_BE_ALLOCA)))
+       || TYPE_RESTRICT (TREE_TYPE (value)))
      pi->pt_malloc = 1;
    else
      pi->pt_anything = 1;

tested with no regressions on i686-linux



More information about the Gcc-patches mailing list