From c80f1d714b82df6a60b601d2315da4d7ad6e0dbf Mon Sep 17 00:00:00 2001
From: Dominic Kempf <dominic.kempf@iwr.uni-heidelberg.de>
Date: Tue, 29 Aug 2017 11:42:58 +0200
Subject: [PATCH] Remove barriers from sum factorization implementations
The y ar enot properly implemented right now, do not seem
to be necessary and conflict with recent changes in loopy.
---
python/dune/perftool/sumfact/realization.py | 5 -----
1 file changed, 5 deletions(-)
diff --git a/python/dune/perftool/sumfact/realization.py b/python/dune/perftool/sumfact/realization.py
index 8922a0b0..3f1afe9c 100644
--- a/python/dune/perftool/sumfact/realization.py
+++ b/python/dune/perftool/sumfact/realization.py
@@ -83,11 +83,6 @@ def _realize_sum_factorization_kernel(sf):
ctags = ctags + ",vec"
vec_shape = (sf.vector_width,)
- # Put a barrier before the sumfactorization kernel
- insn_dep = frozenset({barrier(depends_on=insn_dep,
- within_inames=frozenset(sf.within_inames),
- )})
-
# Decide in which order we want to process directions in the
# sumfactorization. A clever ordering can lead to a reduced
# complexity. This will e.g. happen at faces where we only have
--
GitLab