On Sun, 2020-03-01 at 15:24 -0500, Nicholas Krause wrote: > Greetings Jeff, > > Sorry if I'm bugging you.
[Dropping Jeff from CC since it appears the answer is "yes, you are"] > 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> ssa-iterators.h does not currently include <pthread.h>, so this patch appears to be against something other than master. It looks like you've posted a patch relative to a change you have locally. This isn't helpful. [...snip...] > /*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; Again, this patch is making "extern" various pthread_mutex_t vars that aren't in GCC; it looks like you're generating a patch against a patch. > /* 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. [...snip...] This seems ludicrously overambitious for a first patch. The text of your email suggests that you don't a sense of how difficult what you're suggesting actually is. Even if somehow you managed to generate a working patch that eliminated the garbage collector without regressing the performance of the compiler, it's difficult for us to trust that your patch would work, as you seem to demonstrate a lack of real understanding of the code. I normally attempt to be welcoming to new contributors, but I see that some years ago you submitted a series of apparently nonsensical patches to the Linux kernel; see e.g.: https://lkml.org/lkml/2014/8/4/206 and there was speculation within that development community as to whether you were deliberately trolling them. If you want to be involved in GCC development, please select something small and well-focused for an initial task - to gain experience, and to build trust with the other developers. Otherwise you're wasting your time and ours. Sorry to be blunt. I hope this is constructive, and I don't want to scare off other potential contributors. David
