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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 1B2C33856269 for ; Wed, 18 May 2022 13:16:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B2C33856269 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-433-TKvugQaPMhK-fXkL5rJokA-1; Wed, 18 May 2022 09:16:04 -0400 X-MC-Unique: TKvugQaPMhK-fXkL5rJokA-1 Received: by mail-qt1-f198.google.com with SMTP id d13-20020ac85acd000000b002f3be21793dso1610850qtd.12 for ; Wed, 18 May 2022 06:16:04 -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:cc:references:from:in-reply-to :content-transfer-encoding; bh=JoB/ekSVqr+/ocjuNbu94wm3f7Wr3fg5g20xkIBjUhA=; b=zC7e5OlbL1ph/uFxtqgdswz8IIFtdnJCeMXwLx1A7oaoGJyeFcZXGmuLwNDD+Jm8ST 4MCbDoregI/GkxH1qoZHm+BqBBKBbrH+HD/QZNkyM+iIspchESL/AyTYYfqSMHMHoPCN XFKIOXV5JgR1I0I6y7LS8RAuOPwTb0saNf3HiiXkHokNyaKvbHnjmp0G7uLGGdQV3rV8 FlZ+fou8OQm8kXq3UnZdqNp04E+2mLoHWyzspmdrpj/uLKS5HSNwA4GEa5Pjmp/OX+v1 pDIQQzMzKpTBzv5KqloGpik2/M7/eh7EuxcRl1OY5DMy9bvNypc0QFHURxWGNz5BC49R 1r7g== X-Gm-Message-State: AOAM530yt670qYAWe9ZQeV+dOKJOR2fmtZxHcxVNQFj+OWUhrlzOdysw K+g2eIdI2eufI3KAKvrjxrFxsgXEz/LuhTfNHk74FakBMno2UUDDD+K4u3WSDgZKM1CYHPtSA+n lC/71OPpDfFh0+GjB+w== X-Received: by 2002:a05:622a:4d4:b0:2f3:c529:5f89 with SMTP id q20-20020a05622a04d400b002f3c5295f89mr24638560qtx.158.1652879764255; Wed, 18 May 2022 06:16:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwstS7OS46ykE1vm0umCUM4KCGRtMnpeTv328Q8uvs7l6Sy+cG0rCe5nbyqsOG0FFO2T6P44g== X-Received: by 2002:a05:622a:4d4:b0:2f3:c529:5f89 with SMTP id q20-20020a05622a04d400b002f3c5295f89mr24638532qtx.158.1652879763928; Wed, 18 May 2022 06:16:03 -0700 (PDT) Received: from ?IPV6:2607:fea8:a261:5e00::7704? ([2607:fea8:a261:5e00::7704]) by smtp.gmail.com with ESMTPSA id t85-20020a37aa58000000b0069fc167df92sm1464482qke.82.2022.05.18.06.16.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 May 2022 06:16:01 -0700 (PDT) Message-ID: <7201a3cd-199d-207e-7f0d-bfe433afe991@redhat.com> Date: Wed, 18 May 2022 09:15:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH] PR tree-optimization/31178 - Add rshift side effect. To: Richard Biener , Jakub Jelinek Cc: gcc-patches References: From: Andrew MacLeod In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-CA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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, 18 May 2022 13:16:09 -0000 On 5/18/22 02:41, Richard Biener wrote: > On Tue, May 17, 2022 at 8:41 PM Andrew MacLeod via Gcc-patches > wrote: >> This patch implements side effects of the second operand of a shift >> operation. >> >> given A >> B or A << B, the range of B is restricted to [0, PRECISION_A). >> >> Fortran is currently more permissive than this, allowing the range to be >> [0, PRECISION_A], so this si the value we currently default to in this >> patch. If the fortran front end were adjusted, we could adjust the end >> point. >> >> This currently bootstraps with no regressions on x86_64-pc-linux-gnu. >> >> Is this sufficient, or should I also be checking some other flags which >> may allow other values outside this range to be valid? > I think the "undefined behavior" side-effects are dangerous since > I know of no code that makes sure to clamp the shift argument when > hoisting it. sanitizing shifts will also not help to discover such latent > issues since sanitizing is happening early and it will most definitely > avoid the hoisting itself. > > As to that we _definitely_ want a way to disable this [assumption > that the shift operand is in-range] if we make that assumption > even on IL state after optimizations. > > Candidates to look for are invariant motion, ifcombine, > partial PRE, PRE in general (we possibly hoist such expressions > across function calls that might terminate the program normally). > > That is, what prevents > > if (n > 32) > abort (); > x = i << n; > > to be transformed to > > x = i << n; > if (n > 32) > abort (); > > ? Yes, that's probably a latent issue in some sense but you would > now optimize the if (n > 32) abort () away while previously x would > have an undetermined value but we'd still abort. > > Do you have some statistics on how this particular side-effect > improves code generation? > > Richard. None whatsoever...  just a PR requesting it that has been open for 15 years :-) If we don't want to do this optimization, then we should kill the PR. I can also attach the path to the PR than if anyone cares enough about this functionality, they could pursue the other effects... Andrew