[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #28 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-20 11:13:04 UTC --- (In reply to comment #27) Yes, preserving COMPONENT_REFs would help here, but it is not correct (even for this testcase the types do not match). So you know where the mismatch is? I looked whether I could refuse to IPA-CP just type-mismatched values to restrict pointers but at least when still in IPA-CP, which checks it, the value and the type of the parameter conform to useless_type_conversion_p. So I'll go ahead and commit http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00870.html with the requested tweak.
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #29 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-20 12:56:36 UTC --- Author: jamborm Date: Wed Feb 20 12:56:30 2013 New Revision: 196171 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196171 Log: 2013-02-20 Martin Jambor mjam...@suse.cz PR tree-optimization/55334 * ipa-cp.c (initialize_node_lattices): Disable IPA-CP through and to restricted pointers to arrays. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #26 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-19 12:54:27 UTC --- (In reply to comment #25) That won't work (read: it will cause miscompiles). I believe with the most recent data-dependence reorg I added a bunch of testcases that show how to create breaking testcases ;) Yes, it even already miscompiles a few testcases in the testsuite. I mainly wanted to say that the vectorizer is not the only problem. Which means that we probably want to preserve restrict across IPA optimizations. Another idea, which Honza mentioned last time I spoke to him, was that perhaps not lowering x.u and other COMPONENT_REFs into MEM_REFs would be enough to figure out the accesses do not alias, but I am not sure that is true in gimple (or why tree-inline does this in the first place).
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #27 from rguenther at suse dot de rguenther at suse dot de 2013-02-19 13:49:30 UTC --- On Tue, 19 Feb 2013, jamborm at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #26 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-19 12:54:27 UTC --- (In reply to comment #25) That won't work (read: it will cause miscompiles). I believe with the most recent data-dependence reorg I added a bunch of testcases that show how to create breaking testcases ;) Yes, it even already miscompiles a few testcases in the testsuite. I mainly wanted to say that the vectorizer is not the only problem. Which means that we probably want to preserve restrict across IPA optimizations. Another idea, which Honza mentioned last time I spoke to him, was that perhaps not lowering x.u and other COMPONENT_REFs into MEM_REFs would be enough to figure out the accesses do not alias, but I am not sure that is true in gimple (or why tree-inline does this in the first place). Yes, preserving COMPONENT_REFs would help here, but it is not correct (even for this testcase the types do not match). Richard.
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #25 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13 09:09:09 UTC --- (In reply to comment #24) Created attachment 29429 [details] Experimental patch resolving more dependencies This is my (untested, highly experimental) patch to resolve such dependencies. Basically, it 1) treats MEM_REFs as sort-of COMPONENT_REFs on top INDIRECT_REFs and always pushes the offset index to access_fns of a data reference structure, and 2) relaxes the rule that DR_BASE_OBJECTs need to be the same thing for MEM_REFs of DECLs, where we are happy if the DECLs are the same now. That won't work (read: it will cause miscompiles). I believe with the most recent data-dependence reorg I added a bunch of testcases that show how to create breaking testcases ;)
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #24 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-12 20:10:42 UTC --- Created attachment 29429 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29429 Experimental patch resolving more dependencies This is my (untested, highly experimental) patch to resolve such dependencies. Basically, it 1) treats MEM_REFs as sort-of COMPONENT_REFs on top INDIRECT_REFs and always pushes the offset index to access_fns of a data reference structure, and 2) relaxes the rule that DR_BASE_OBJECTs need to be the same thing for MEM_REFs of DECLs, where we are happy if the DECLs are the same now. It is successful to the extent that vectorization takes place, however the resulting code is even slower. The problem seems to be that IPA-CP does not only inhibit vectorization, it also apparently inhibits moving loop invariant loads out of the loop. E.g. the second load in BB 7 of the clone _22 = MEM[(real(kind=8)[4] *)x + 58071104B][0]; is moved up to BB 4 in the original function. The vectorizer then also complains about mgrid.f:191: note: Detected interleaving MEM[(real(kind=8)[4] *)x + 58071104B][0] and MEM[(real(kind=8)[4] *)x + 58071104B][1] mgrid.f:191: note: Detected interleaving MEM[(real(kind=8)[4] *)x + 58071104B][0] and MEM[(real(kind=8)[4] *)x + 58071104B][2] mgrid.f:191: note: Detected interleaving MEM[(real(kind=8)[4] *)x + 58071104B][0] and MEM[(real(kind=8)[4] *)x + 58071104B][3] mgrid.f:191: note: Detected interleaving MEM[(real(kind=8)[4] *)x + 58071104B][1] and MEM[(real(kind=8)[4] *)x + 58071104B][2] mgrid.f:191: note: Detected interleaving MEM[(real(kind=8)[4] *)x + 58071104B][1] and MEM[(real(kind=8)[4] *)x + 58071104B][3] mgrid.f:191: note: Detected interleaving MEM[(real(kind=8)[4] *)x + 58071104B][2] and MEM[(real(kind=8)[4] *)x + 58071104B][3] I am convinced there is no reasonably easy fix for this to juggle with in stage 4 and so I am going to submit a patch disabling propagation to and through restrict pointers to arrays. However, I would very much prefer to revert it on trunk immediately after 4.8 is branched off (and thus keep this bug opened). As we try to do more and more IPA stuff on Fortran, we will be bumping into this more often.
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|rguenth at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org 2012-12-21 12:25:35 UTC --- Nothing to fix for me - it's the IPA-CP decision that pessimizes things.
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #17 from Jan Hubicka hubicka at ucw dot cz 2012-12-21 13:49:15 UTC --- Nothing to fix for me - it's the IPA-CP decision that pessimizes things. Well, replacing parameter by known constant should not pessimize in general... Honza
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #18 from Richard Biener rguenth at gcc dot gnu.org 2012-12-21
14:01:33 UTC ---
(In reply to comment #17)
Nothing to fix for me - it's the IPA-CP decision that pessimizes things.
Well, replacing parameter by known constant should not pessimize in general...
True, but replacing restrict parameter with sth non-restrict may be.
The language spec allows me to write
void foo (int * restrict p, int * restrict q, int n)
{
for (i = 0; i n; ++i)
p[i] = q[n-i];
}
and call it with foo (a[0], a[100], n) when I know that with this
particular n it will not alias.
But without knowing 'n' (like in the mgrid case) there is no chance
that we can re-discover this non-aliasing when you propagate a[0]
and a[100].
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org 2012-12-21 14:08:24 UTC --- Btw, one thing to improve would be the excessive number of aliasing runtime checks the vectorizer currently generates. That would also help himeno. What is missing here is conservative merging of tests (thus making them slightly less precise for the sake of reducing their number). We create different tests for, say, R vs. U(I1, I2, I3) and R vs. U(I1-1,I2, I3). It's of course not that trivial, otherwise somebody would have done it already (see vect_prune_runtime_alias_test_list - we only merge equal range tests and do not try to use a convex hull to cover multiple tests with one).
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-21 14:10:19 UTC --- There would be if we had ADD_RESTRICT or something similar. But we don't right now, so supposedly it would be better to avoid such IPA-CP changes if it removes restrict for now.
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #21 from Richard Biener rguenth at gcc dot gnu.org 2012-12-21 14:12:18 UTC --- (In reply to comment #20) There would be if we had ADD_RESTRICT or something similar. I think that would not help as we'd likely propagate constants through it. But yes, it would be one step closer to preserving it.
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #22 from Jan Hubicka hubicka at ucw dot cz 2012-12-21 14:22:28 UTC --- There would be if we had ADD_RESTRICT or something similar. But we don't right now, so supposedly it would be better to avoid such IPA-CP changes if it removes restrict for now. We would also have to disable inlining of functions with restrict parameters (in mgrid case now both ipa-cp and inliner makes the regressions). I am not quite sure it is desirable behaviour. Honza
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #23 from Richard Biener rguenth at gcc dot gnu.org 2012-12-21
14:27:18 UTC ---
In fact there are a few dependences we can solve:
191: versioning for alias required: can't determine dependence between
MEM[(real(kind=8)[0:D.1986] *)x + 20247552B][_20] and
MEM[(real(kind=8)[0:D.1989] *)x + 37823552B][_20]
from
Creating dr for MEM[(real(kind=8)[0:D.1986] *)x + 20247552B][_20]
analyze_innermost: success.
base_address: x
offset from base address: (ssizetype) ((sizetype) (((_7 - stride.11_6)
+ pretmp_791) + pretmp_813) * 8)
constant offset from base address: 20247568
step: 8
aligned to: 8
base_object: MEM[(real(kind=8)[0:D.1986] *)x + 20247552B]
Access function 0: {{(stride.9_4 * 2 + pretmp_792) + 2, +,
stride.9_4}_2, +, 1}_3
and
Creating dr for MEM[(real(kind=8)[0:D.1983] *)x][_20]
analyze_innermost: success.
base_address: x
offset from base address: (ssizetype) ((sizetype) (((_7 - stride.11_6)
+ pretmp_791) + pretmp_813) * 8)
constant offset from base address: 16
step: 8
aligned to: 8
base_object: MEM[(real(kind=8)[0:D.1983] *)x]
Access function 0: {{(stride.9_4 * 2 + pretmp_792) + 2, +,
stride.9_4}_2, +, 1}_3
we hit:
/* If the references do not access the same object, we do not know
whether they alias or not. */
if (!operand_equal_p (DR_BASE_OBJECT (a), DR_BASE_OBJECT (b), 0))
{
DDR_ARE_DEPENDENT (res) = chrec_dont_know;
return res;
}
but for the case the access functions are the same we can conclude the
accesses cannot alias if the base_objects cannot alias (danger! data-ref
does not record an access size, so with the same access function
but only 1-byte offset in base_object this can lead to false disambiguations,
so it might in the end not be that easy ...) This size issue is also
why we cannot translate the base_object internal offset into an access
function (see testcases I added for bugs we had there)
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 15:33:38 UTC --- (In reply to comment #4) Hmm, this does not help. The problem is indeed that we are not able to figure out that the accesses into subarrays of X are mutually independent. Martin, Michael, I think you are more familiar with MEM_REF, can you take a look? Well, the accesses are lowered to like (compute_affine_dependence stmt_a: _21 = MEM[(real(kind=8)[0:D.1986] *)x + 20247552B][_20]; stmt_b: _23 = MEM[(real(kind=8)[0:D.1983] *)x][_20]; ) - dependence analysis failed this lowering of x.u vs. x.v (just guessing) does't mix well with array-based accesses. That is, we cannot translate this kind of accesses to independently indexed dimensions as dependence analysis likes to have. Another issue is that the number of iterations is not constant but 190: === get_loop_niters ===Analyzing # of iterations of loop 2 exit condition [2, + , 1](no_overflow) != _2 + -1 bounds on difference of bases: 0 ... 2147483644 result: # of iterations (unsigned int) _2 + 4294967293, bounded by 2147483644 so we cannot see that in the above case _20 would not run over to the other sub-array of x. The only way to retain this knowledge is not to lower the high-level form x.u and x.v but to keep it (which in the end won't help because we cannot reconstruct x.u[_20] or x.v[_20] in any valid way). Or to retain restrict information - which means _not_ doing IPA-CP. So, if you can from (compute_affine_dependence stmt_a: _21 = MEM[(real(kind=8)[0:D.1986] *)x + 20247552B][_20]; stmt_b: _23 = MEM[(real(kind=8)[0:D.1983] *)x][_20]; ) - dependence analysis failed prove that the base addresses (MEM[(real(kind=8)[0:D.1986] *)x + 20247552B] and MEM[(real(kind=8)[0:D.1983] *)x]) are different objects then initialize_data_dependence_relation can compute the dependence and all would be fine. refs_may_alias_p would be the thing to fix to make them not alias (as you can see the arrays have unknown upper bounds, so it's not possible to prove they are not the same).
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #14 from Richard Biener rguenth at gcc dot gnu.org 2012-12-07 10:11:26 UTC --- Let me have a look here. I think the issue is that IPA-CP removes Fortran restrict argument handling and exposes DECLs that data-ref analysis is not handling very well. Thus, it effectively drops restrict. Maybe it simply shouldn't do that.
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|mgrid regression (ipa-cp|[4.8 Regression] mgrid |disables vectorization) |regression (ipa-cp disables ||vectorization)
