[Bug target/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742 --- Comment #7 from 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 target/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742 rsand...@gcc.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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742 --- Comment #5 from Richard Guenther 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742 Ramana Radhakrishnan changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #4 from Ramana Radhakrishnan 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742 Ramana Radhakrishnan 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 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; : 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) ∈ D.3755_76 = in.53_75 + 2080; : # vect_pout2.26_63 = PHI # ivtmp.33_31 = PHI # ivtmp.37_60 = PHI 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 ; else goto ; : 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #2 from Ramana Radhakrishnan 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742 Richard Guenther 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 2011-07-14 09:08:55 UTC --- Looks like a target issue.
