From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) by sourceware.org (Postfix) with ESMTPS id A336A384BC3F for ; Wed, 13 Jul 2022 16:01:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A336A384BC3F Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-10bec750eedso14553377fac.8 for ; Wed, 13 Jul 2022 09:01:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=XrJZm10EIMV/kMswGicYq6WTyimmnFU23eV1V9DLtQI=; b=QWwgQz0QcXSzREHDe/zAaAUV06Ixt+RKpXYbuU8knrhqHe5W6YhjwYjNHA7zzxmSQc 9o7OMIVVXR1xHvovzJL9GrzR20NEZyhoRFYmOwWxzXOrr+b4F7BhstCBeXbfB0mGQpOw wB4nfwKmWqUpoYO0ONWQ5OVNREp+j1YXqNYBKelDgdcGgvcCrSp3MN2kzb03vhf1pDx9 fux1nG8Cmw9+FGns8pWyVPt8ao+/eGjILniIm7aNUsjlGXsBBl7SlbEm0a3gjsuVgUkI z2FP0/TT82wBlIDNa08Dc6uprfj/t72hTmDFWPhHRJDfdcozm1depAM1JbIY7fhz3jnt 4EwQ== X-Gm-Message-State: AJIora+Dzr4FCo4kbc59yVE5O1UAyIrc38KEeXbXrZwjGL9LQbwH/rTO TVmFzfP34UhKGUjDr5nG2oDQINUkC+Q= X-Google-Smtp-Source: AGRyM1tyYdHnBu10muzSlgwtk8Zvbk1EvWnVc1N5SIUHBmV+a7hj693I/jcdoM9nCBbJC7jtUEY3Yg== X-Received: by 2002:a05:6870:a19c:b0:10b:972f:228f with SMTP id a28-20020a056870a19c00b0010b972f228fmr2199438oaf.16.1657728064481; Wed, 13 Jul 2022 09:01:04 -0700 (PDT) Received: from [172.31.0.204] (c-73-98-188-51.hsd1.ut.comcast.net. [73.98.188.51]) by smtp.gmail.com with ESMTPSA id a18-20020a0568300b9200b0061c309b1dc2sm4894773otv.39.2022.07.13.09.01.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Jul 2022 09:01:03 -0700 (PDT) Message-ID: <1e6ee886-7fc6-494a-9216-ba6b5855a88a@gmail.com> Date: Wed, 13 Jul 2022 10:01:02 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 2/3] tree-cfg: do not duplicate returns_twice calls Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <20220114182047.6270-3-amonakov@ispras.ru> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 13 Jul 2022 16:01:08 -0000 On 7/13/2022 1:13 AM, Richard Biener via Gcc-patches wrote: > On Tue, Jul 12, 2022 at 10:10 PM Alexander Monakov wrote: >> >> Apologies for the prolonged silence Richard, it is a bit of an obscure topic, >> and I was unsure I'd be able to handle any complications in a timely manner. >> I'm ready to revisit it now, please see below. >> >> On Mon, 17 Jan 2022, Richard Biener wrote: >> >>> On Fri, Jan 14, 2022 at 7:21 PM Alexander Monakov wrote: >>>> A returns_twice call may have associated abnormal edges that correspond >>>> to the "second return" from the call. If the call is duplicated, the >>>> copies of those edges also need to be abnormal, but e.g. tracer does not >>>> enforce that. Just prohibit the (unlikely to be useful) duplication. >>> The general CFG copying routines properly duplicate those edges, no? >> No (in fact you say so in the next paragraph). In general I think they cannot, >> abnormal edges are a special case, so it should be the responsibility of the >> caller. >> >>> Tracer uses duplicate_block so it should also get copies of all successor >>> edges of that block. It also only traces along normal edges. What it might >>> miss is abnormal incoming edges - is that what you are referring to? >> Yes (I think its entire point is to build a "trace" of duplicated blocks that >> does not have incoming edges in the middle, abnormal or not). >> >>> That would be a thing we don't handle in duplicate_block on its own but >>> that callers are expected to do (though I don't see copy_bbs doing that >>> either). I wonder if we can trigger this issue for some testcase? >> Oh yes (in fact my desire to find a testcase delayed this quite a bit). >> When compiling the following testcase with -O2 -ftracer: >> >> __attribute__((returns_twice)) >> int rtwice_a(int), rtwice_b(int); >> >> int f(int *x) >> { >> volatile unsigned k, i = (*x); >> >> for (k = 1; (i = rtwice_a(i)) * k; k = 2); >> >> for (; (i = rtwice_b(i)) * k; k = 4); >> >> return k; >> } >> >> tracer manages to eliminate the ABNORMAL_DISPATCHER block completely, so >> the possibility of transferring control back to rtwice_a from rtwice_b >> is no longer modeled in the IR. I could spend some time "upgrading" this >> to an end-to-end miscompilation, but I hope you agree this is quite broken >> already. >> >>> The thing to check would be incoming abnormal edges in >>> can_duplicate_block_p, not (only) returns twice functions? >> Unfortunately not, abnormal edges are also used for computed gotos, which are >> less magic than returns_twice edges and should not block tracer I think. > I think computed gotos should use regular edges, only non-local goto should > use abnormals... > > I suppose asm goto also uses abnormal edges? > > Btw, I don't see how they in general are "less magic". Sure, we have an > explicit receiver (the destination label), but we can only do edge inserts > if we have a single computed goto edge into a block (we can "move" the > label to the block created when splitting the edge). I suspect treating them like abnormals probably came from the inability to reliably split them way back when we introduced RTL GCSE and the like. Jeff