-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compiler: Patch race conditions due to storage-related dependencies #1903
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1903 +/- ##
==========================================
+ Coverage 88.35% 89.64% +1.29%
==========================================
Files 210 210
Lines 35460 35523 +63
Branches 5350 5361 +11
==========================================
+ Hits 31329 31843 +514
+ Misses 3643 3183 -460
- Partials 488 497 +9
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments, but looks GTG
usave = TimeFunction(name='usave', grid=grid, save=10) | ||
v = TimeFunction(name='v', grid=grid) | ||
|
||
eq = [Eq(v[time, x, y], usave)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpicking: Eq(usave, v)
bit more readable and makes bit more "sense"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want time
in place of t
since otherwise the loop will be tagged SEQUENTIAL due to the presence of uindices. But I want it fully PARALLEL to trigger the issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's fin,e I meant having usave
as lhs mostly but again just nitpicking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, I see what you mean now...
well in backward propagators you do have usave's on the RHS :)
@@ -143,14 +143,15 @@ class Cpu64NoopOperator(Cpu64OperatorMixin, CoreOperator): | |||
def _specialize_iet(cls, graph, **kwargs): | |||
options = kwargs['options'] | |||
platform = kwargs['platform'] | |||
compiler = kwargs['compiler'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: not for here but long run, should be gather all of these into a CompilerOptions
class to avoid carrying all these multiple arguments everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's a fair point, but I actually don't mind supplying the passes only the strict necessary rather than a big batch of things
devito/passes/iet/parpragma.py
Outdated
def supported(): | ||
# Not all backend compilers support array reduction! | ||
# Here are the known unsupported ones: | ||
if isinstance(self.compiler, GNUCompiler) and \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SHould we havd something similar for osx clang + openmp
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, yeah, probably..
73856fc
to
9b5c3d7
Compare
9b5c3d7
to
7681225
Compare
devito/ir/support/basic.py
Outdated
@memoized_meth | ||
def is_const(self, dim): | ||
""" | ||
True if a constant depedence, that is no Dimensions involved, False otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo depedence
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
870fcaa
to
f55e68a
Compare
if simd_level: | ||
assert 'omp simd' in iterations[simd_level].pragmas[0].value | ||
try: | ||
assert 'omp for collapse' in iterations[0].pragmas[0].value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that mean that you do not see "omp for collapse" in every case as before?
If this is the case I would prefer another variable in parametrization to whether "omp for collapse" is expected or not.
If we still see "omp for collapse" it should be out of the try-except.
Ideally we could use parameters to avoid the try-except. THese parameters would reflect the expected positions of omp and simd pragmas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
false, it is caught in the except
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then why do we not have:
assert 'omp for collapse' in iterations[0].pragmas[0].value
try:
if simd_level:
assert 'omp simd' in iterations[simd_level].pragmas[0].value
except:
# E.g. gcc-5 doesn't support array reductions, so the compiler will
# generate different legal code
assert not Ompizer._support_array_reduction(configuration['compiler'])
The "omp for collapse is always in iterations[0], right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it just false we can add a similar var to simd_level, like omp_level to get either 0 or None...
i.e.
if omp_level:
assert 'omp for collapse' in iterations[0].pragmas[0].value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "omp for collapse is always in iterations[0], right?
no, with gcc-5 it will be in the innermost loop*, as it prefers thread parallelism over simd parallelism
- it's a bit more complicated than that... it actually depends on the number of physical and logical cores of the underlying platform, as collapsing may further change what the candidate-selector ends up choosing. Hence the loose(ish)
any(...)
in the except branch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GTG from me once green!
if simd_level: | ||
assert 'omp simd' in iterations[simd_level].pragmas[0].value | ||
try: | ||
assert 'omp for collapse' in iterations[0].pragmas[0].value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okk
fixes #1901
fixes #1902