[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

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

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
For

      DO CONCURRENT( I=ABS(LS-LE):MIN(LS+LE,7):2 )
        CALL THREEJ(LO,LE,LE,0,0,0,C)
        CALL THREEJ(LO,LE,LE,0,0,0,C)
      END DO

      B=0.
      DO CONCURRENT( I=ABS(LS-LE):MIN(LS+LE,7):2 )
        CALL THREEJ(LO,LE,LE,MO,-2*MO-1,MO+1,C)
        B = B + C
      END DO

the FE annotates both loops with IVDEP:

      if (forall_tmp->do_concurrent)
        cond = build2 (ANNOTATE_EXPR, TREE_TYPE (cond), cond,
                       build_int_cst (integer_type_node,
                                      annot_expr_ivdep_kind));

but this seems to have an adverse effect in case the last threej is inlined
(which it is only in case the first two are ipa-cp'ed).

Ok, so we have

 <mem_ref 0x7ffff6774c30
    type <real_type 0x7ffff68ac348 real(kind=4) SF
        size <integer_cst 0x7ffff6891e28 constant 32>
        unit size <integer_cst 0x7ffff6891e40 constant 4>
        align 32 symtab 0 alias set 1 canonical type 0x7ffff68ac348 precision
32
        pointer_to_this <pointer_type 0x7ffff68ac888> reference_to_this
<reference_type 0x7ffff6a74a80>>
    tree_0 tree_1
    arg 0 <addr_expr 0x7ffff677c1e0
        type <pointer_type 0x7ffff68ac888 type <real_type 0x7ffff68ac348
real(kind=4)>
            public unsigned DI
            size <integer_cst 0x7ffff6891be8 constant 64>
            unit size <integer_cst 0x7ffff6891c00 constant 8>
            align 64 symtab 0 alias set 8 canonical type 0x7ffff68ac888>

        arg 0 <var_decl 0x7ffff6694120 c type <real_type 0x7ffff68ac348
real(kind=4)>
            addressable used SF file /tmp/t.f90 line 82 col 0 size <integer_cst
0x7ffff6891e28 32> unit size <integer_cst 0x7ffff6891e40 4>
            align 32 context <function_decl 0x7ffff6a72c00 sub1> chain
<var_decl 0x7ffff66941b0 i>>
        /tmp/t.f90:102:0 start: /tmp/t.f90:102:0 finish: /tmp/t.f90:102:0>
    arg 1 <integer_cst 0x7ffff669c738 type <reference_type 0x7ffff6a74b28>
constant 0>>

but then there is

c.68_18 = c;

 <var_decl 0x7ffff6694120 c
    type <real_type 0x7ffff68ac348 real(kind=4) SF
        size <integer_cst 0x7ffff6891e28 constant 32>
        unit size <integer_cst 0x7ffff6891e40 constant 4>
        align 32 symtab 0 alias set 1 canonical type 0x7ffff68ac348 precision
32
        pointer_to_this <pointer_type 0x7ffff68ac888> reference_to_this
<reference_type 0x7ffff6a74a80>>
    addressable used SF file /tmp/t.f90 line 82 col 0 size <integer_cst
0x7ffff6891e28 32> unit size <integer_cst 0x7ffff6891e40 4>
    align 32 context <function_decl 0x7ffff6a72c00 sub1> chain <var_decl
0x7ffff66941b0 i>>

which is not detected as equal and things go haywire (alias analysis would
detect they alias but we have safelen and thus detecting equal things as
equal is now a strict requirement!).

This is probably a case that can be easily fixed _but_ LIM is not ready to
detect, say, a.b.c and MEM[&a + 8] as equal.  This means we somehow need to
conservatively(!) compute must-aliases to make the safelen handing in LIM
safe.  Esp. for accesses with non-constant address this is impossible,
like in a loop nest (like this) with the outer loop safelen and the LIM
pass after IV optimization which might re-write things in a way that
a) isn't fully consistent, b) can have un-CSEd expressions.

Bah.

Now - the special case above is sth to fix anyways (for !safelen this will
result in a missed store motion).

Will poke at this a bit.