[Bug tree-optimization/49742] New: ICE for gcc.dg/vect/O3-pr39675-2.c on ARM

[Bug tree-optimization/49742] New: ICE for gcc.dg/vect/O3-pr39675-2.c on ARM

[janis at gcc dot gnu.org]

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

           Summary: ICE for gcc.dg/vect/O3-pr39675-2.c on ARM
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: janis@gcc.gnu.org
                CC: rguenth@gcc.gnu.org


Test gcc.dg/vect/O3/pr39675-2.c fails with an ICE on arm-none-linux-gnueabi:

Executing on host: arm-none-linux-gnueabi-gcc
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c
  -mfpu=neon -mfloat-abi=softfp -ffast-math -ftree-vectorize
-fno-vect-cost-model -O2 -fdump-tree-vect-details -O3 -fno-ipa-cp-clone -S  -o
O3-pr39675-2.s    (timeout = 300)
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c:
In function 'foo':
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c:27:1:
error: insn does not satisfy its constraints:
(insn 95 37 44 2 (set (reg:V2SI 95 d16 [orig:177 vect_array.21_I_lsm0.31 ]
[177])
        (mem/u/c/i:V2SI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [3 S8 A64]))
750 {*neon_movv2si}
     (nil))
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c:27:1:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

The same failure results if the test program is compiled with options
"-mfpu=neon -mfloat-abi=softfp -O3".

The test starts failing with this patch:

2011-06-30  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/46787
        * tree-data-ref.c (dr_address_invariant_p): Remove.
        (find_data_references_in_stmt): Invariant accesses are ok now.
        * tree-vect-stmts.c (vectorizable_load): Handle invariant
        loads.
        * tree-vect-data-refs.c (vect_analyze_data_ref_access): Allow
        invariant loads.

        * gcc.dg/vect/vect-121.c: New testcase.

    r175704 | rguenth | 2011-06-30 13:27:43 +0000 (Thu, 30 Jun 2011)

[Bug target/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm-*-*
          Component|tree-optimization           |target
   Target Milestone|---                         |4.7.0
            Summary|ICE for                     |[4.7 Regression] ICE for
                   |gcc.dg/vect/O3-pr39675-2.c  |gcc.dg/vect/O3-pr39675-2.c
                   |on ARM                      |on ARM

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-07-14 09:08:55 UTC ---
Looks like a target issue.

[Bug target/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

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

--- Comment #2 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2011-07-14 23:43:18 UTC ---
That looks like a constant pool reference to a V2SImode constant and the Uv
constraint doesn't allow it. Need to dig a bit further. 


Ramana

[Bug target/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.07.15 00:16:49
     Ever Confirmed|0                           |1

--- Comment #3 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2011-07-15 00:16:49 UTC ---
Before jumping in to the target I'm not sure I totally understand what the tree
optimizers are doing here. 


Why are the tree level forms producing ... 

 vect_array.21_I_lsm0.31_37 = vect_array.21[0];


dump_tree_optimized shows : 


  unsigned int in.53;
  unsigned int D.3755;
  void * D.3750;
  unsigned int D.3748;
  int[8] * D.3749;
  void * D.3744;
  unsigned int ivtmp.37;
  unsigned int ivtmp.33;
  vector(2) int vect_array.21_I_lsm0.31;
  vector(2) int * vect_pout2.26;
  vector(2) int vect_array.21[4];
  vector(2) int vect_var_.12;
  vector(2) int vect_var_.11;
  vector(2) int vect_var_.10;
  vector(2) int vect_var_.9;

<bb 2>:
  vect_array.21_I_lsm0.31_37 = vect_array.21[0];
  ivtmp.33_59 = (unsigned int) &in[8];
  ivtmp.37_4 = (unsigned int) &out[8];
  in.53_75 = (unsigned int) &in;
  D.3755_76 = in.53_75 + 2080;

<bb 3>:
  # vect_pout2.26_63 = PHI <vect_pout2.26_64(3), &out2(2)>
  # ivtmp.33_31 = PHI <ivtmp.33_3(3), ivtmp.33_59(2)>
  # ivtmp.37_60 = PHI <ivtmp.37_61(3), ivtmp.37_4(2)>
  D.3748_12 = ivtmp.33_31 + 4294967264;
  D.3749_13 = (int[8] *) D.3748_12;
  D.3744_6 = (void *) ivtmp.33_31;
  vect_var_.9_42 = MEM[base: D.3744_6, offset: 4294967264B];
  vect_var_.10_44 = MEM[base: D.3744_6, offset: 4294967272B];
  vect_var_.11_46 = MEM[base: D.3744_6, offset: 4294967280B];
  vect_var_.12_48 = MEM[base: D.3744_6, offset: 4294967288B];
  vect_array.21 = LOAD_LANES (MEM[(int[512] *)D.3749_13]);
  D.3750_21 = (void *) ivtmp.37_60;
  MEM[base: D.3750_21, offset: 4294967264B] = vect_var_.9_42;
  MEM[base: D.3750_21, offset: 4294967272B] = vect_var_.10_44;
  MEM[base: D.3750_21, offset: 4294967280B] = vect_var_.11_46;
  MEM[base: D.3750_21, offset: 4294967288B] = vect_var_.12_48;
  MEM[base: vect_pout2.26_63, offset: 0B] = vect_array.21_I_lsm0.31_37;
  vect_pout2.26_64 = vect_pout2.26_63 + 8;
  ivtmp.33_3 = ivtmp.33_31 + 32;
  ivtmp.37_61 = ivtmp.37_60 + 32;
  if (ivtmp.33_3 != D.3755_76)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 4>:
  return;




Look at vect_array.21_I_lsm0.31_37 - it's being initialized even before
vect_array.21 has been ! I'm not sure I quite follow the transformations here
till this point. 


Ramana

[Bug target/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

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

--- Comment #4 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2011-07-15 00:22:45 UTC ---
Predictive commoning appears to be doing this. 

RichardS: you mentioned something about looking at a predictive commoning
issue. Does this ring a bell ? 

Ramana

[Bug target/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-07-18 08:24:40 UTC ---
This must be an artifact of the load-/store-lanes stuff.  It looks like they
play foul with aliasing.  It might also be that predictive commoning simply
does not know how to re-materialize calls (they seem to be analyzed as
only loading the memory arguments by data-reference analysis, so if predcom
tries to split them that will obviously fail - not sure if it's a good idea
to do the call handling the way get_references_in_stmt does).

[Bug target/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM

[rsandifo at gcc dot gnu.org]

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

rsandifo@gcc.gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |rsandifo at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2011-07-19 09:35:46 UTC ---
(In reply to comment #4)
> Predictive commoning appears to be doing this. 
> 
> RichardS: you mentioned something about looking at a predictive commoning
> issue. Does this ring a bell ? 

Yeah, it is indeed the same thing.  Handling gimple_call_lhs_ptr in
get_references_in_stmt seems to fix it.  I'm testing a patch now.

Richard

[Bug target/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2011-07-19 12:37:06 UTC ---
Author: rsandifo
Date: Tue Jul 19 12:37:03 2011
New Revision: 176446

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176446
Log:
gcc/
    PR tree-optimization/49742
    * tree-data-ref.c (get_references_in_stmt): Treat the lhs of a call
    as a potential write.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-data-ref.c

[Bug tree-optimization/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM

[rsandifo at gcc dot gnu.org]

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

rsandifo@gcc.gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
          Component|target                      |tree-optimization
         Resolution|                            |FIXED

--- Comment #8 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2011-07-19 12:46:05 UTC ---
Fixed on trunk.