From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113264 invoked by alias); 29 Mar 2019 14:28:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 113254 invoked by uid 89); 29 Mar 2019 14:28:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=Injection, HX-Spam-Relays-External:!192.168.1.101!, H*RU:!192.168.1.101!, H*r:ip*192.168.1.101 X-HELO: mail-qt1-f171.google.com Received: from mail-qt1-f171.google.com (HELO mail-qt1-f171.google.com) (209.85.160.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 29 Mar 2019 14:28:42 +0000 Received: by mail-qt1-f171.google.com with SMTP id v32so2492474qtc.10 for ; Fri, 29 Mar 2019 07:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=U5pBVmZew9uqEzTTP7E7qvl05FL4uc/IDnMxl8ZV6Ik=; b=tKudBj9q8jr3W63oHeptp2JsfOCs+ajrsNU8hN20xCZDUBJUxrjcKPKBYvzp3DLDXR X+uKdUL90LZ1kCq8QzSIrgn3FTLq5W2DKZgaZ2lPjOrmesnwhQS0+YwTdiOYK0c0qpnB 8FFlFF7ANJjm2IPIm8pMeWwfDVw8FrpO0y+gl5ZoDXh7unJUAAEOYy5fqlEEK079Yv/F ev7yJ7qt4KwomuxzzNeyrnn1RqXBrguQRJHEtVRMqvPYvmlmRhlIevbrEuRA1FL+vFwY bvqsWza8s2Ke8bDk9/BPQxlMKRs3R/tyvaCAlQq7SC/JRC1be1CHIgu/UeehJcLLsYoT 1mAQ== Return-Path: Received: from [192.168.1.101] (173-230-163-230.cable.teksavvy.com. [173.230.163.230]) by smtp.googlemail.com with ESMTPSA id x5sm1067095qki.26.2019.03.29.07.28.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 07:28:39 -0700 (PDT) Subject: Re: GSOC Proposal To: Richard Biener Cc: GCC Development References: <4327491a-395b-bee0-145a-eddd8f64b0ba@gmail.com> From: nick Message-ID: <63e78666-ceca-94d8-9ac4-101130afab4c@gmail.com> Date: Fri, 29 Mar 2019 14:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00255.txt.bz2 On 2019-03-29 5:08 a.m., Richard Biener wrote: > On Thu, 28 Mar 2019, nick wrote: > >> >> >> On 2019-03-28 4:59 a.m., Richard Biener wrote: >>> On Wed, Mar 27, 2019 at 6:31 PM nick wrote: >>>> >>>> Greetings All, >>>> >>>> I've already done most of the work required for signing up for GSoC >>>> as of last year i.e. reading getting started, being signed up legally >>>> for contributions. >>>> >>>> My only real concern would be the proposal which I started writing here: >>>> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit?usp=sharing >>>> >>>> The biography and success section I'm fine with my bigger concern would be the project and roadmap >>>> section. The roadmap is there and I will go into more detail about it in the projects section as >>>> need be. Just wanted to known if the roadmap is detailed enough or can I just write out a few >>>> paragraphs discussing it in the Projects Section. >>> >>> I'm not sure I understand either the problem analysis nor the project >>> goal parts. What >>> shared state with respect to garbage collection are you talking about? >>> >>> Richard. >>> >> I just fixed it. Seems we were discussing RTL itself. I edited it to >> reflect those changes. Let me know if it's unclear or you would actually >> like me to discuss some changes that may occur in the RTL layer itself. >> >> >> I'm glad to be more exact if that's better but seems your confusion was >> just what layer we were touching. > > Let me just throw in some knowledge here. The issue with RTL > is that we currently can only have a single function in this > intermediate language state since a function in RTL has some > state in global variables that would differ if it were another > function. We can have multiple functions in GIMPLE intermediate > language state since all such state is in a function-specific > data structure (struct function). The hard thing about moving > all this "global" state of RTL into the same place is that > there's global state in the various backends (and there's > already a struct funtion 'machine' part for such state, so there's > hope the issue isn't as big as it could be) and that some of > the global state is big and only changes very rarely. > That said, I'm not sure if anybody knows the full details here. > > So as far as I understand you'd like to tackle this as project > with the goal to be able to have multiple functions in RTL > state. > > That's laudable but IMHO also quite ambitious for a GSoC > project. It's also an area I am not very familiar with so > I opt out of being a mentor for this project. > While I'm aware of three areas where the shared state is an issue currently: 1, Compiler's Proper 2. The expand_functions 3. RTL 4.Garbage Collector Or maybe a project to be more explicit about regions of the code that assume that the garbage- collector can't run within them?[3] (since the GC is state that would be shared by the threads). This is what we were discussing previously and I wrote my proposal for that. You however seem confused about what parts of the garbage collector would be touched. That's fine with me, however seems you want be to be more exact about which part is touched. My questions would be as it's changed back to the garbage collector project: https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit 1. Your confusion about which part of the garbage collector is touched doesn't really make sense s it's for the whole garbage collector as related to shared state? 2. Injection was my code here in phase 3 for the callers of the new functions or macros, perhaps this is not needed as the work with the garbage collector is enough? 3. Am I not understanding this project as I thought I was in the proposal I wrote? Seems your more confusing my wording probably so I'm going to suggest one of two things here: a) I'm going to allow you to make comments with what's confusing you and it needs that's the issue here more than anything else so I sent you a link and please comment where you are having issues with this not be clear for you: Or maybe a project to be more explicit about regions of the code that assume that the garbage- collector can't run within them?[3] (since the GC is state that would be shared by the threads). as that's the actual project b) Just comment here about the wording that's an issue for you or where you want more exact wording Sorry and hopefully this is helps you understand where I'm going, Nick > Richard. > >> Nick >>>> Any other comments are welcome as well as I write it there, >>>> Nick >> >