which is the case of e.g. *.omp_data_i_23(D).a ref in simd3.f90 -O2
-fopenmp -msse2, but not the D.3815[0] case tested during can_sm_ref_p - the
D.3815[0] = 0; as well as something = D.3815[0]; stmt found in the outer loop
obviously can be dependent on many of the loads and/or stores in the loop, be
it "omp simd array" or not.
Say for
void
foo (int *p, int *q)
{
#pragma omp simd
for (int i = 0; i < 1024; i++)
p[i] += q[0];
}
sure, q[0] can't alias p[0] ... p[1022], the earlier iterations could write
something that changes its value, and then it would behave differently from
using VF = 1024, where everything is performed in parallel.
Though, actually, it can alias, just it would have to write the same value as
was there. So, if this is used to determine if it is safe to hoist the load
before the loop, it is fine, if it is used to determine if &q[0] >= &p[0] &&
&q[0] <= &p[1023], then it is not fine.
For aliasing of q[0] and p[1023], I don't see why they couldn't alias in a
valid program. #pragma omp simd I think guarantees that the last iteration is
executed last, it isn't necessarily executed last alone, it could be, or
together with one before last iteration, or (for simdlen INT_MAX) even all
iterations can be done concurrently, in hw or sw, so it is fine if it is
transformed into:
int temp[1024], temp2[1024], temp3[1024];
for (int i = 0; i < 1024; i++)
temp[i] = p[i];
for (int i = 0; i < 1024; i++)
temp2[i] = q[0];
/* The above two loops can be also swapped, or intermixed. */
for (int i = 0; i < 1024; i++)
temp3[i] = temp[i] + temp2[i];
for (int i = 0; i < 1024; i++)
p[i] = temp3[i];
/* Or the above loop reversed etc. */
If you have:
int
bar (int *p, int *q)
{
q[0] = 0;
#pragma omp simd
for (int i = 0; i < 1024; i++)
p[i]++;
return q[0];
}
i.e. something similar to what misbehaves in simd3.f90 with the change, then
the answer is that q[0] isn't guaranteed to be independent of any references in
the simd loop.
2016-07-07 16:57 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
On Thu, Jul 7, 2016 at 3:24 PM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
Richard,
Did you meas the following check enhancement:
outer = loop_outer (loop);
/* We consider REF defined in LOOP as independent if at least 2 loop
iterations are not dependent. */
if ((loop->safelen > 1
|| (outer && outer->safelen > 1))
&& bitmap_bit_p (&memory_accesses.refs_in_loop[loop->num], ref->id))
return true;
which allows us to consider reference x[0] as invariant for the test
#pragma omp simd
for (i = 0; i< 100; i++)
{
y[i] = i * 2;
for (j = 0; j < 100; j++)
z[j] += x[0];
}
Moving statement
_9 = *x_19(D);
(cost 20) out of loop 1.
outer loops will be automatically considered by outermost_indep_loop
which eventually
calls the function you are patching.
I was questioning the added test
&& bitmap_bit_p (&memory_accesses.refs_in_loop[loop->num], ref->id))
and still do not understand why you need that. It makes us only consider the
loop of ref itself when looking at safelen (but not refs that belong
to inner loops
of loop).
Richard.
2016-07-07 11:46 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
On Wed, Jul 6, 2016 at 4:42 PM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
Richard,
I don't understand your question and how it is related to proposed patch.
2016-07-06 16:55 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
On Wed, Jul 6, 2016 at 3:50 PM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
See for example Jakub comments for 70729.
But how can the check be valid given a
#pragma omp simd
for (;;)
{
for (;;)
...ref in question...
}
can be transformed to
#pragma omp simd
for (;;)
{
...ref in question...
...ref in question..
...
}
by means of unrolling?
The bitmap check would return false for the not unrolled inner loop
and true for the inner unrolled loop.
So it cannot be correct.
(not sure why this is all off-list btw)
Richard.
Richard.
2016-07-06 16:25 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
On Wed, Jul 6, 2016 at 1:43 PM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
I did not learn LIM detailed but I see on the following example
#pragma omp simd
for (i = 0; i< 100; i++)
{
y[i] = i * 2;
for (j = 0; j < 100; j++)
z[j] += x[0];
}
that only inner,ost loop is handled:
Memory reference in loop#2 1: *_7
Memory reference in loop#2 2: *x_19(D)
Memory reference in loop#1 3: *_3
Basic block 3 (loop 1 -- depth 1):
Basic block 4 (loop 2 -- depth 2):
Loop#2 is innermost
Querying dependency of refs 2 and 1: dependent.
Querying dependencies of ref 2 in loop 2: dependent
well, LIM doesn't bother to check against refs in an outer loop if
refs in the inner loop are already dependent.
Loop unroll of inner loop does not invalidate 'safelen' of outer one
accordingly with safelen definition.
So why do you need the bitmap_bit_p check then?
Richard.
2016-07-06 14:23 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
On Wed, Jul 6, 2016 at 1:17 PM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
Richard,
LIM phase considers only innermost loops and does not handle loop
nests, so in your case the innermost loop (j) does not have non-zero
safelen.
Huh? LIM considers loop nests just fine. And yes, the innermost loop
does not have safelen but shouldn't it? Consider the inner loop being unrolled
by GCC so it is removed - should that then invalidate the outer loop safelen
because innermost loop refs now appear in the outer loop?
Richard.
2016-07-06 13:34 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
On Wed, Jul 6, 2016 at 11:50 AM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
Richard,
I pointed out in the commentary that REF is defined inside loop and
this check is related to this statement. Should I clarify it?
+ /* We consider REF defined in LOOP as independent if at least 2 loop
+ iterations are not dependent. */
Yes, I fail to see why x[0] should not be disambiguated against y[i] in
#pragma GCC loop ivdep
for (i...)
{
y[i] = ...;
for (j...)
... = x[0];
}
REF is always inside the loop nest with LOOP being the outermost loop.
Richard.
2016-07-06 12:38 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
On Tue, Jul 5, 2016 at 4:56 PM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
Hi All,
Here is a simple fix to cure regressions introduced by my fix for
70729. Patch also contains minor changes in test found by Jakub.
Bootstrapping and regression testing did not show any new failures.
Is it OK for trunk?
+ && bitmap_bit_p (&memory_accesses.refs_in_loop[loop->num], ref->id))
So safelen does not apply to refs in nested loops? The added comment only
explains the safelen check change but this also requires explanation.
Richard.
ChangeLog:
2016-07-05 Yuri Rumyantsev <ysrumyan@gmail.com>
PR tree-optimization/71734
* tree-ssa-loop-im.c (ref_indep_loop_p_1): Consider REF defined in
LOOP as independent if at least two loop iterations are not dependent.
gcc/testsuite/ChangeLog:
* g++.dg/vect/pr70729.cc: Delete redundant dg options, fix style.