From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id D8B9B3858C60 for ; Wed, 29 Sep 2021 15:59:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D8B9B3858C60 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-349-Y-aFiugjMSqonL1cxVylIw-1; Wed, 29 Sep 2021 11:59:27 -0400 X-MC-Unique: Y-aFiugjMSqonL1cxVylIw-1 Received: by mail-qk1-f198.google.com with SMTP id k3-20020a05620a414300b0045e623cd1afso9792223qko.20 for ; Wed, 29 Sep 2021 08:59:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ANqWRga1bPDcFMlYHvWB9HWU7AkGUkIqeDFR6z4i98w=; b=PKeA6vSffPN4sKXCsOtRRmbCDYe5JwBah34f2qvt8rFBle1YuI94h/Nq3awYt+PP4j f8UQgghG5vnLgFk6SpHlIMyabg3uzHRp0b4zfBG8eIIHRYOQ6Y3jGErUW1aqe42ZQkSY NafcjmSQMmC1ujXPFzEOFY46599qjstWzuhdHVEw8QPE2wGxNZwfKVOErVgkvdFDKQwX pB2EfZgmodUSZILN/niGoVSBcOvvPMsEzsRX83Mn3ZLWZxIdkXcO7MjWRxfBuvPzk/DO 6hjXj+IVNRW+i7Dr2RzXMemKu+hNoUVjKpiOxGBIPlX9RQA4sH4B4CRIewl8JFJzkbzc vMhQ== X-Gm-Message-State: AOAM533Wp2RthmhEb085xMs75WaZ8FWXshwpeKNkX6kfU77Oh58wfrwv EZw9qZO9sKXtxbGLtr0iq8AqT75D97mO8dcGMVU33ukRk+GLyiGmDl0CDEI4WbehHd4zgOOmdmg YtFHfD/u6dvFjJiSmoPgqO8fsfWpTklo8xwA5Ghcz7q7v9Cuut7pAQduKv7DS0l8PRjdRUA== X-Received: by 2002:ac8:4313:: with SMTP id z19mr712645qtm.356.1632931166350; Wed, 29 Sep 2021 08:59:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyqGu0erzyYGfuEdu+Pehar/IiZkLNpNsCNeJwViqlnxYKzq/aLVtlIS7RF189jQDSAyMymwA== X-Received: by 2002:ac8:4313:: with SMTP id z19mr712609qtm.356.1632931166003; Wed, 29 Sep 2021 08:59:26 -0700 (PDT) Received: from [192.168.0.102] ([104.219.123.55]) by smtp.gmail.com with ESMTPSA id e17sm161308qty.28.2021.09.29.08.59.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Sep 2021 08:59:24 -0700 (PDT) Subject: Re: [PATCH] Loop unswitching: support gswitch statements. To: Jeff Law , Richard Biener Cc: GCC Patches References: <7791e850-f74d-8c1c-f67c-e02f3f6e007d@redhat.com> From: Andrew MacLeod Message-ID: <5b5bc177-232e-c3eb-f977-89774ee21477@redhat.com> Date: Wed, 29 Sep 2021 11:59:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-CA X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 15:59:30 -0000 On 9/29/21 11:28 AM, Jeff Law wrote: > > > On 9/29/2021 9:20 AM, Andrew MacLeod via Gcc-patches wrote: >> On 9/29/21 4:43 AM, Richard Biener wrote: >>> On Tue, Sep 28, 2021 at 10:39 PM Andrew MacLeod >>> wrote: >>>> On 9/28/21 7:50 AM, Richard Biener wrote: >>>>> On Wed, Sep 15, 2021 at 10:46 AM Martin Liška wrote: >>>>>>     /* Unswitch single LOOP.  NUM is number of unswitchings done; >>>>>> we do not allow >>>>>> @@ -269,6 +311,7 @@ tree_unswitch_single_loop (class loop *loop, >>>>>> int num) >>>>>>       class loop *nloop; >>>>>>       unsigned i, found; >>>>>>       tree cond = NULL_TREE; >>>>>> +  edge cond_edge = NULL; >>>>>>       gimple *stmt; >>>>>>       bool changed = false; >>>>>>       HOST_WIDE_INT iterations; >>>>>> @@ -311,11 +354,12 @@ tree_unswitch_single_loop (class loop >>>>>> *loop, int num) >>>>>>       bbs = get_loop_body (loop); >>>>>>       found = loop->num_nodes; >>>>>> >>>>>> +  gimple_ranger ranger; >>>>> ISTR constructing/destructing ranger has a non-negligible overhead - >>>>> is it possible >>>>> to keep it live for a longer time (note we're heavily modifying >>>>> the CFG)? >>>> >>>> There is some overhead.. right now we determine all the imports and >>>> exports for each block ahead of time, but thats about it. We can make >>>> adjustments for true on demand clients like this so that even that >>>> doesnt happen. we only do that so we know ahead of time which >>>> ssa-names >>>> are never used in outgoing edges, and never even have to check those. >>>> Thats mostly an optimization for heavy users like EVRP.  If you >>>> want, I >>>> can make that an option  so there virtually no overhead >>>> >>>> More importantly, the longer it remains alive, the more "reuse" of >>>> ranges you will get..   If there is not a pattern of using variables >>>> from earlier in the program it wouldnt really matter much. >>>> >>>> In Theory, modifying the IL should be fine, it happens already in >>>> places, but its not extensively tested under those conditions yet. >>> Note it's modifying the CFG as well. >> bah, thats what I meant.   as long as the IL is changed and CFG >> updated to match, it should in theory work.  And as long as existing >> SSA_NAMEs dont have their meaning changes..  ie reusing an SSA_NAME >> to have a  different definition is likely to cause problems without >> telling ranger that an SSA_NAME is now different. > There is an API somewhere which resets the global information that we > call for these scenarios.   But that assumes we know when an name is > going to be reused or moved to a point where the global information > isn't necessary accurate anymore.  It's not heavily used as these > cases are relatively rare. > > The nastier case is when we release an SSA_NAME because it was dead > code, then later re-cycle it.  If we're going to have Ranger instances > live across passes, then that becomes a much bigger concern. we'd mostly need to add an API call when we de-register ssa-names and add them back into the free list to the get_range_query() instance to let it know an SSA_NAME is now dead.   if no ranger is active, it just wouldnt do anything. If ranger is alive, it would flush its global cache of that ssa_name and move it back to not-processed. I think thats all that would be required.. at least for that scenario.  My hope was to make it live across passes eventually...  at least until we do something major.  For short gaps it would be beneficial, so that if a threader runs right after a VRP pass, its fully populated already. Andrew