Greetings Jeff,
Sorry if I'm bugging you. I've already sent off some work on IPA passes
with a few questions here:
https://gcc.gnu.org/ml/gcc/2020-02/msg00247.html
And locking SSA iterators:
From: Nicholas Krause<xerofo...@gmail.com>
In order to start making SSA be muti-threaded safe I'm proposing
adding locks as implemented in this patch. There are two ways
of doing the locking and both have there advantage/disadvantage:
1.Rewrite the marcos to be functions and make the locking internal
to SSA iterators themselves. This removes possible inlining of the
marcos as currently implemented.
2. Don't change the marcos but add the proposed locks and update
the manual to warn about locking/unlocking the correct lock or
series of locks when iterating over SSA or other similar nodes.
Not sure which is better. Comments are also welcome.
Signed-off-by: Nicholas Krause<xerofo...@gmail.com>
---
gcc/ssa-iterators.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/ssa-iterators.h b/gcc/ssa-iterators.h
index 65d8e3b..1c8c2ad 100644
--- a/gcc/ssa-iterators.h
+++ b/gcc/ssa-iterators.h
@@ -16,11 +16,11 @@ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
Public License
You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3. If not see
<http://www.gnu.org/licenses/>. */
-#include <pthread.h>
#ifndef GCC_SSA_ITERATORS_H
#define GCC_SSA_ITERATORS_H
+#include <pthread.h>
/* Immediate use lists are used to directly access all uses for an SSA
name and get pointers to the statement for each use.
@@ -70,9 +70,9 @@ struct imm_use_iterator
};
/*IMM Iterator Mutex*/
-pthread_mutex_t imm_iteration_mutex;
+extern pthread_mutex_t imm_iteration_mutex;
/*IMM_STMT Iterator Mutex*/
-pthread_mutex_t imm_stmt_iterator_mutex;
+extern pthread_mutex_t imm_stmt_iterator_mutex;
/* Use this iterator when simply looking at stmts. Adding, deleting or
modifying stmts will cause this iterator to malfunction. */
@@ -153,11 +153,11 @@ struct ssa_op_iter
};
/*SSA Iterator Mutex*/
-pthread_mutex_t ssa_iteration_mutex;
+extern pthread_mutex_t ssa_iteration_mutex;
/*PHI Iterator Mutex*/
-pthread_mutex_t phi_iteration_mutex;
+extern pthread_mutex_t phi_iteration_mutex;
/*PHI_STMT Iterator Mutex*/
-pthread_mutex_t phi_stmt_iterator_mutex;
+extern pthread_mutex_t phi_stmt_iterator_mutex;
/* NOTE: Keep these in sync with doc/tree-ssa.texi. */
/* These flags are used to determine which operands are returned during
-- 1.8.3.1
I was wondering and maybe its a dumb idea but seems removing the garbage
collector for the most
part is going to be possible and I'm going to investigate into it
further this week.
Seems that GTY() wrappers are really just one of two use cases after
looking through a few
files:
Empty Wrappers that don't have a pointer can just be removed due to them
now allocating
memory themselves but callers doing so. Or the second case of having a
pointer(s) which
need a destructor for them.
However for the other wrappers which take arguments I was wondering if
its possible to
just use unique_ptr with a custom allocater. Seems that's basically what
the internal
garbage collector is. I'm not sure of the current status of the C++11
move and sorry
if I did not help out as much with that under than the early discussion.
Take care,
Nick
