[Bug tree-optimization/54935] New: No way to do if converison

[Bug tree-optimization/54935] New: No way to do if converison

[ysrumyan at gmail dot com]

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

             Bug #: 54935
           Summary: No way to do if converison
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ysrumyan@gmail.com


In a process of analyzing of gcc peformance on x86 including vectorization we
found out that on spec2006/462.libquantum (e.g.file gates.c, routine
quantum_cnot) vectorization of simple loop is not performed since if-conversion
has not happened even if we pass explicit option to if-convert store stmt aka  
"-ftree-loop-if-convert-stores". I can illustrate it on the following simple
test-case:

extern int a[100], b[100];
void foo(int n)
{
  int i;

  for (i=1; i<n;i++) {
    if (a[i] != b[i])
    a[i] = b[i] + 1;
  }
}

Note that if I insert into loop "a[0] = 0;" stmt if conversion will happen but
this is not suitable for the whole benchmark. I also tried to use lto that
could detect writable memory access but without any success. I assume that we
can detect writable accesses without having unconditional write to that memory
but simple through object type specification of a given object. BTW I don't
know how array a[] with external declaration must be defined to put in
read-only section. Please, also check gcc external definition of
"-ftree-loop-if-convert-stores" option that does not match with the following
commentary:

/* Return true when the memory references of STMT won't trap in the
   if-converted code.  There are two things that we have to check for:

   - writes to memory occur to writable memory: if-conversion of
   memory writes transforms the conditional memory writes into
   unconditional writes, i.e. "if (cond) A[i] = foo" is transformed
   into "A[i] = cond ? foo : A[i]", and as the write to memory may not
   be executed at all in the original code, it may be a readonly
   memory.  To check that A is not const-qualified, we check that
   there exists at least an unconditional write to A in the current
   function.

   - reads or writes to memory are valid memory accesses for every
   iteration.  To check that the memory accesses are correctly formed
   and that we are allowed to read and write in these locations, we
   check that the memory accesses to be if-converted occur at every
   iteration unconditionally.  */

static bool
ifcvt_memrefs_wont_trap (gimple stmt, VEC (data_reference_p, heap) *refs)
{
  return write_memrefs_written_at_least_once (stmt, refs)
    && memrefs_read_or_written_unconditionally (stmt, refs);
}

[Bug tree-optimization/54935] No way to do if converison

[ysrumyan at gmail dot com]

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

Yuri Rumyantsev <ysrumyan at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |4.8.0

--- Comment #1 from Yuri Rumyantsev <ysrumyan at gmail dot com> 2012-10-15 13:44:46 UTC ---
I see such gcc behavior starting from 4-6 version.

[Bug tree-optimization/54935] No way to do if converison

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-15 14:06:16 UTC ---
We cannot if-convert this because the store to a[i] may trap as it may be
in .rodata.

That is, the following is valid C:

t1.c:
const int a[100];
const int b[100];

t2.c:
your testcase

with LTO we could arrange information on readonly-ness of variables to be
available.  Honza, is there already a suitable predicate for this?

If other compilers do this transformation without LTO they can be trivially
tricked to generate wrong code.

[Bug tree-optimization/54935] No way to do if converison

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-10-15 14:58:14 UTC ---
On Mon, 15 Oct 2012, rguenth at gcc dot gnu.org wrote:

> We cannot if-convert this because the store to a[i] may trap as it may be
> in .rodata.
> 
> That is, the following is valid C:
> 
> t1.c:
> const int a[100];
> const int b[100];
> 
> t2.c:
> your testcase

No, that's not valid.  int[100] and const int[100] are not compatible 
types.

[Bug tree-optimization/54935] No way to do if converison

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> 2012-10-15 15:43:25 UTC ---
On Mon, 15 Oct 2012, joseph at codesourcery dot com wrote:

> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54935
> 
> --- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-10-15 14:58:14 UTC ---
> On Mon, 15 Oct 2012, rguenth at gcc dot gnu.org wrote:
> 
> > We cannot if-convert this because the store to a[i] may trap as it may be
> > in .rodata.
> > 
> > That is, the following is valid C:
> > 
> > t1.c:
> > const int a[100];
> > const int b[100];
> > 
> > t2.c:
> > your testcase
> 
> No, that's not valid.  int[100] and const int[100] are not compatible 
> types.

It happens in real code though :(  I suppose we could eventually
relax this though.

[Bug tree-optimization/54935] No way to do if converison

[izamyatin at gmail dot com]

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

--- Comment #5 from Igor Zamyatin <izamyatin at gmail dot com> 2012-11-27 08:40:44 UTC ---
What do you think about the way we can relax this?

[Bug tree-optimization/54935] No way to do if converison

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-11-27
     Ever Confirmed|0                           |1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> 2012-11-27 09:16:01 UTC ---
ISTR the argument that one can do mprotect on allocated memory, thus one way
to relax this is to see if the access is to a decl and check if that resides
in .rodata.  Other than that there is of course the issue of introducing
store data races - thus if !write_memrefs_written_at_least_once we may
not introduce an unconditional store in the C++ memory model (or in the
transactional memory model).

[Bug tree-optimization/54935] No way to do if converison

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
           Keywords|                            |missed-optimization