[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |tkoenig at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Working on it a little bit.

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #6)
> Working on it a little bit.

I believe that the middle end prefers the use of ARRAY_RANGE_REF to the use of
memcpy. The reason is that with ARRAY_RANGE_REF it knows what type it has while
memcpy transfers everything into a pointer - and it cannot then simply recover
the value.

For a range-ref example, see class_array_data_assign - or Ada.


For instance, 
    b = a(1:12)
can be represented as

  lhs = gfc_get_descriptor_dimension (lhs_desc);
  rhs = gfc_get_descriptor_dimension (rhs_desc);

  lhs = build4_loc (input_location, ARRAY_RANGE_REF, type, lhs,
                    lhs_offset, NULL_TREE, NULL_TREE);
  rhs = build4_loc (input_location, ARRAY_RANGE_REF, type, rhs,
                    rhs_offset, NULL_TREE, NULL_TREE);
followed by
  gfc_add_modify (block, lhs, rhs);

Note that the number of elements is contained in the "type". In the example
above, one can use:
  type = TREE_TYPE (lhs)   (add before before the build4_loc call)
as "lhs" is a full array with a known size.

If one doesn't have a full array (or an allocatable array), one has to build
the type oneself - for instance by using:

  type = 
    build_array_type (type, build_range_type (gfc_array_index_type,
                                              gfc_index_zero_node,
                                              number_of_elements));

where type is either gfc_typenode_for_spec (&expr2->ts) or, e.g.,
  gfc_get_element_type (TREE_TYPE (lhs)).


Disclaimer: The example above should be correct. However, I have not fully
understood how RANGE_REF works, i.e. what the last two arguments (here:
NULL_TREE) do.

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Disclaimer: The example above should be correct. However, I have not fully
> understood how RANGE_REF works, i.e. what the last two arguments (here:
> NULL_TREE) do.

It works exactly like ARRAY_REF as far as they are concerned.

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31016

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|tkoenig at gcc dot gnu.org         |unassigned at gcc dot gnu.org

--- Comment #9 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Not working on this at the moment.

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2007-04-30 17:25 -------
> AFAIK the libc memset/cpy choose the algorithm depending the the size etc., so
> you have to do a big block to make up for all the overhead. But what could be
> done for small multidimensional arrays would be to "flatten" the nested loops
> into the equivalent 1D loop? Perhaps this is something better done in the
> middle end?

Well libc's memcpy/memset does optimize by size but the compiler also optimizes
memcpy/memset if the size is constant and also based on the alignment so it
could optimize it down to two instructions instead of a couple (and on PPC,
with -maltivec, GCC can optimize using VMX also which makes the instruction
count go down even more).


-- 


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

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[jb at gcc dot gnu dot org]

------- Comment #4 from jb at gcc dot gnu dot org  2007-04-29 11:46 -------
I don't think you can use memset for populating real arrays except when the
value is 0.0; the bit patterns would be different, as memset takes an int
argument which is actually converted to unsigned char.

AFAIK the libc memset/cpy choose the algorithm depending the the size etc., so
you have to do a big block to make up for all the overhead. But what could be
done for small multidimensional arrays would be to "flatten" the nested loops
into the equivalent 1D loop? Perhaps this is something better done in the
middle end?


-- 

jb at gcc dot gnu dot org changed:

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


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

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[tkoenig at gcc dot gnu dot org]

------- Comment #3 from tkoenig at gcc dot gnu dot org  2007-03-01 19:34 -------
Confirmed.


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-03-01 19:34:52
               date|                            |


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

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2007-03-01 19:26 -------
And another example for compile-time known sizes:

subroutine bar(a,n)
 implicit none
 integer :: n
 real :: a(n),b(12)
 a(1:12) = b

 a(2:n) = b
! Here, n is unknown, but it is only valid if the shapes of b an a are the same
end subroutine


-- 


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

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2007-03-01 19:15 -------
subroutine bar(a,b,n)
 implicit none
 integer :: n
 real :: a(n,n), b(n,n)
 a = b
end subroutine

For that example example, the overhead is even more obvious. One needs to run
only:

for (int i = 0; i < n*n; i++)
  a[i] = b[i]

However, gfortran generates two loops and a whole stack of temporary variables.

Analogously for

subroutine bar(a,n)
 implicit none
 integer :: n
 real :: a(n,n)
 a = 12
end subroutine


-- 


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