[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away

[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2010-06-21 15:17 -------
Created an attachment (id=20966)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20966&action=view)
Test case


-- 


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

[Bug middle-end/44612] New: -flto -fwhole-program: Never read variable not optimized away

[burnus at gcc dot gnu dot org]

Follow up to PR 41137.

Using the Intel compiler, the following program takes 0s for the loops (real
time: 0.005s); however, with
 gfortran -fdump-tree-original -fwhole-program -flto -ffast-math -march=native
-O3 cont.f90
GCC needs 1.142s.

Expected:
* GCC also optimizes the loops away if the variable "a" is never read (but only
set)


Removing the !! comments prevents ifort from optimizing the loops away; still
the performance is with (real time) 0.650s twice as good as the one of GCC.


-- 
           Summary: -flto -fwhole-program: Never read variable not optimized
                    away
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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

[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-22 11:19 -------
Your testcase doesn't build:

contiguous.f90:54.5:

REAL,contiguous :: a(:,:,:,:)
     1
Error: Invalid character in name at (1)
contiguous.f90:55:

a(:,:,:,:)=0.0
1
Error: Unclassifiable statement at (1)
contiguous.f90:15.8:

CALL SC(a)
        1
Error: Rank mismatch in argument 'a' at (1) (0 and 4)


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2010-06-22 11:37 -------
It does, you need latest trunk though (r161079 or later).


-- 


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

[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2010-06-22 12:26 -------
(In reply to comment #2)
> Your testcase doesn't build:
> REAL,contiguous :: a(:,:,:,:)
>      1
> Error: Invalid character in name at (1)

If you want to test it with other compilers than the latest trunk, you can
simply take out the "contiguous" - though, as Jakub mentioned, it should build
with the latest GCC trunk builds. 

 * * *


C test case:

$ gcc -flto -fwhole-program -O3 -std=c99 test.c && time ./a.out
Start
Done

real    0m0.699s
user    0m0.676s
sys     0m0.004s


#include <stdio.h>
#define SIZE 40000

void s4 (float *restrict a)
{
  (void) __builtin_memset ((void *) a, 0, sizeof(float)*SIZE);
}


int main ()
{
  static float a[SIZE];
  int i;
  printf("Start\n");
  for (i = 0; i < SIZE; i++)
    s4 (a);
  printf("Done\n");
  return 0;
}


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-06-22 12:26:35
               date|                            |


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

[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2010-06-22 13:14 -------
Similarly for:
  static void s4 (float *restrict a) {
    for (int j=1; j < SIZE; j++) a[j] = 0;
  }

Except that this uses
   MEM[symbol: a, index: ivtmp.25_27, offset: 16] = { 0.0, 0.0, 0.0, 0.0 };
in the optimized dump rather than "memset". But also here: the loop is not
optimized away.


-- 


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

[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2010-06-22 13:46 -------
Confirmed.

DSE doesn't remove memset or memcpy calls.

We also do not have a flag to mark functions only clobbering local or
incoming memory (thus effectively not have side-effects if the argument
reachable memory is unused after a call).


-- 


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

[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2010-06-22 14:12 -------
Well, RTL DSE to some extent knows about memset.
And, for tree DSE handling it would be much easier and desirable.


-- 


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

[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
For what it is worth, still occurs with on mainline (GCC 11).


(In reply to Richard Biener from comment #6)
> Confirmed.
> 
> DSE doesn't remove memset or memcpy calls.
> 
> We also do not have a flag to mark functions only clobbering local or
> incoming memory (thus effectively not have side-effects if the argument
> reachable memory is unused after a call).

(In reply to Jakub Jelinek from comment #7)
> Well, RTL DSE to some extent knows about memset.
> And, for tree DSE handling it would be much easier and desirable.