[Bug fortran/40598] New: Some missed optimizations in array assignment

[Bug fortran/40598] New: Some missed optimizations in array assignment

[pault at gcc dot gnu dot org]

The fix for PR40551 made me realise that there are some assignment
optimizations that are missed:

  integer :: array (3, 3), source (3, 3)
  array = 0
  array(:, 1) = 0             ! could use __builtin_memcpy
  array(1,:) = 0
  source = array              ! uses __builtin_memcpy
  source(:,1) = array (:,2)   ! could use __builtin_memcpy
  source(1,:) = array (2,:)
  source = reshape ([1,2,3,4,5,6,7,8,9],[3,3]) ! uses __builtin_memcpy
  array(:,1) = [1,2,3]        ! could use __builtin_memcpy
end


At present, there is only a test that the lhs array is full.  Any contiguous
reference could take these opportunities too.  Some work will be required with
the helper functions but this is not a big deal.

I'll take it on.

Paul


-- 
           Summary: Some missed optimizations in array assignment
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: pault at gcc dot gnu dot org
        ReportedBy: pault at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2009-06-30 09:39 -------
I guess for zeroing you want memset, not memcpy.  Note that in most of the
cases you should be able to use direct assignments from {} (to zero) or
the source.  For selecting continuous ranges of an array you can use
ARRAY_RANGE_REF.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[burnus at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]



------- Comment #2 from burnus at gcc dot gnu dot org  2009-06-30 09:46 -------
  array(:,1) = 0
would then become
  ARRAY_RANGE_REF <array, ...> = { }

and

  array(:,1) = [1,2,3]
would then become
  ARRAY_RANGE_REF <array, ...> = { 1,2,3 }

If I recall correctly, using memcopy/memset causes alias analysis problems as
  pointerOpteratingFunction(array,...)
marks "array" as maybe-aliasing, cf. PR 40168 and especially
http://gcc.gnu.org/ml/fortran/2009-05/msg00287.html

 * * *

ARRAY_REF
These nodes represent array accesses. The first operand is the array; the
second is the index. To calculate the address of the memory accessed, you must
scale the index by the size of the type of the array elements. The type of
these expressions must be the type of a component of the array. The third and
fourth operands are used after gimplification to represent the lower bound and
component size but should not be used directly; call array_ref_low_bound and
array_ref_element_size instead.

ARRAY_RANGE_REF
These nodes represent access to a range (or “slice”) of an array. The operands
are the same as that for ARRAY_REF and have the same meanings. The type of
these expressions must be an array whose component type is the same as that of
the first operand. The range of that array type determines the amount of data
these expressions access.

(from http://gcc.gnu.org/onlinedocs/gccint/Expression-trees.html)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[pault at gcc dot gnu dot org]

------- Comment #3 from pault at gcc dot gnu dot org  2009-06-30 09:54 -------
(In reply to comment #1)
> I guess for zeroing you want memset, not memcpy.  Note that in most of the

***blush*** - yes, you are right, of course!

> cases you should be able to use direct assignments from {} (to zero) or
> the source.  For selecting continuous ranges of an array you can use
> ARRAY_RANGE_REF.
>

I was going to enquire if such a facility exists.

Thanks

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[pault at gcc dot gnu dot org]

------- Comment #4 from pault at gcc dot gnu dot org  2009-06-30 12:57 -------
Modifying trans-expr (gfc_trans_zero_assign) to:

  tmp =  build4 (ARRAY_RANGE_REF, TREE_TYPE (dest), dest, 
                  build_int_cst (gfc_array_index_type, 3),
                  NULL_TREE, NULL_TREE);

  /* If we are zeroing a local array avoid taking its address by emitting
     a = {} instead.  */
  if (!POINTER_TYPE_P (TREE_TYPE (dest)))
    return build2 (MODIFY_EXPR, void_type_node,
                   tmp, build_constructor (TREE_TYPE (tmp), NULL));

produces:

  array[3 ...] = {};
  {
    struct __st_parameter_dt dt_parm.2;

    dt_parm.2.common.filename = &"test.f90"[1]{lb: 1 sz: 1};
    dt_parm.2.common.line = 4;
    dt_parm.2.common.flags = 128;
    dt_parm.2.common.unit = 6;
    _gfortran_st_write (&dt_parm.2);

for:

  integer :: array (3, 3)
  array = 1
  array = 0
  print *, array
end

and the output is:

[prt@localhost tmp]# ./a.out
           1           1           1           0           0           0       
   0           0           0
Segmentation fault

So the lower bound for the reference seems to be OK but I have not understood
how to set the upper bound.  If I set argument three, the lower bound is reset
to zero and the size of the array reference is determined by arg 3.  This also
gets rid of the seg fault.

I obviously do not have the faintest idea of what I am doing!  I notice as well
that the ARRAY_RANGE_REF is not used very much.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2009-07-01 07:51 -------
(In reply to comment #4)
Here, I do not get any segfault/problem with valgrind (for gfortran and a.out).

>   tmp =  build4 (ARRAY_RANGE_REF, TREE_TYPE (dest), dest, 
>                   build_int_cst (gfc_array_index_type, 3),

I actually do not understand why "3" works. If I read gccint (cf. comment 2)
correctly I would have expect that one needs to passe the byte size. But it
seems to work as the dump / a.out indicates.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[pault at gcc dot gnu dot org]

------- Comment #6 from pault at gcc dot gnu dot org  2009-07-01 08:23 -------
I might as well confirm it:-)

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-07-01 08:23:08
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2009-07-01 09:43 -------
  tmp =  build4 (ARRAY_RANGE_REF, TREE_TYPE (dest), dest, 
                  build_int_cst (gfc_array_index_type, 3),
                  NULL_TREE, NULL_TREE);

to set the upper bound correctly you have to build a new array type instead
of re-using TREE_TYPE (dest).  The types TYPE_DOMAIN will specify the size
of the slice.  Thus,

  slice_type = build_array_type (TREE_TYPE (TREE_TYPE (dest)),
                                 build_index_type (build_int_cst
(gfc_array_index_type, slice-size - 1)));

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[pault at gcc dot gnu dot org]

------- Comment #8 from pault at gcc dot gnu dot org  2009-07-01 10:51 -------
Richard,

> to set the upper bound correctly you have to build a new array type instead
> of re-using TREE_TYPE (dest).  The types TYPE_DOMAIN will specify the size
> of the slice.  Thus,
> 
>   slice_type = build_array_type (TREE_TYPE (TREE_TYPE (dest)),
>                                  build_index_type (build_int_cst
> (gfc_array_index_type, slice-size - 1)));

Brilliant! Thanks

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[pault at gcc dot gnu dot org]

------- Comment #9 from pault at gcc dot gnu dot org  2009-07-01 11:02 -------
Richard,

It even works!

Thanks again

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
   Last reconfirmed|2009-07-01 08:23:08         |2009-07-01 11:02:14
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[dfranke at gcc dot gnu dot org]

------- Comment #10 from dfranke at gcc dot gnu dot org  2010-05-07 21:02 -------
(In reply to comment #9)
> It even works!

Paul, any news here? This looks very useful!
See also PR41137.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[pault at gcc dot gnu dot org]

------- Comment #11 from pault at gcc dot gnu dot org  2010-05-08 12:57 -------
(In reply to comment #10)
> (In reply to comment #9)
> > It even works!
> 
> Paul, any news here? This looks very useful!
> See also PR41137.
> 

Daniel,

I totally forgot about this one.  I had a first tinker since comment #9 and it
looks to be do-able.

I'll put it on the list.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598

[Bug fortran/40598] Some missed optimizations in array assignment

[dfranke at gcc dot gnu dot org]

------- Comment #12 from dfranke at gcc dot gnu dot org  2010-05-08 20:58 -------
Paul, I'm always unsure with these kind of things; PR31009 and PR31016 may, or
may not, be more of the same ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598