Skip to content
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

Merged
merged 5 commits into from
Apr 13, 2022

Conversation

FabioLuporini
Copy link
Contributor

fixes #1901
fixes #1902

@FabioLuporini FabioLuporini added the bug-C bug in the generated code label Apr 12, 2022
@codecov
Copy link

codecov bot commented Apr 12, 2022

Codecov Report

Merging #1903 (f55e68a) into master (30434ef) will increase coverage by 1.29%.
The diff coverage is 95.83%.

@@            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     
Impacted Files Coverage Δ
devito/ir/clusters/algorithms.py 95.30% <ø> (ø)
devito/passes/clusters/asynchrony.py 37.33% <0.00%> (+23.99%) ⬆️
devito/arch/compiler.py 54.59% <75.00%> (+3.00%) ⬆️
tests/test_dle.py 97.12% <90.00%> (-1.01%) ⬇️
devito/passes/iet/parpragma.py 90.13% <94.11%> (+0.67%) ⬆️
devito/core/cpu.py 100.00% <100.00%> (ø)
devito/core/gpu.py 95.63% <100.00%> (+4.99%) ⬆️
devito/ir/support/basic.py 92.41% <100.00%> (+0.49%) ⬆️
devito/mpi/halo_scheme.py 97.31% <100.00%> (+0.04%) ⬆️
devito/passes/clusters/buffering.py 94.88% <100.00%> (+0.13%) ⬆️
... and 28 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 30434ef...f55e68a. Read the comment docs.

Copy link
Contributor

@mloubout mloubout left a 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

devito/passes/clusters/buffering.py Show resolved Hide resolved
usave = TimeFunction(name='usave', grid=grid, save=10)
v = TimeFunction(name='v', grid=grid)

eq = [Eq(v[time, x, y], usave)]
Copy link
Contributor

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"

Copy link
Contributor Author

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

Copy link
Contributor

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

Copy link
Contributor Author

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']
Copy link
Contributor

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.

Copy link
Contributor Author

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

def supported():
# Not all backend compilers support array reduction!
# Here are the known unsupported ones:
if isinstance(self.compiler, GNUCompiler) and \
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, yeah, probably..

@memoized_meth
def is_const(self, dim):
"""
True if a constant depedence, that is no Dimensions involved, False otherwise.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo depedence

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

if simd_level:
assert 'omp simd' in iterations[simd_level].pragmas[0].value
try:
assert 'omp for collapse' in iterations[0].pragmas[0].value
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okk

Copy link
Contributor

@georgebisbas georgebisbas left a 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okk

@FabioLuporini FabioLuporini merged commit e1b1692 into master Apr 13, 2022
@FabioLuporini FabioLuporini deleted the fix-issues-1901-1696 branch April 13, 2022 14:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-C bug in the generated code
Projects
None yet
3 participants