From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id 178053858C3A for ; Tue, 11 Jan 2022 08:17:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 178053858C3A Received: by mail-wm1-x329.google.com with SMTP id l12-20020a7bc34c000000b003467c58cbdfso896407wmj.2 for ; Tue, 11 Jan 2022 00:17:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=pbwZyrMs6idscWr6p6z/KunR1Y3Zgl+So0pGVhyxcvI=; b=fKD+c+KtG2EVMD1D4xtPlq+f4DqguszWa6Rz+ULqJBuVKRXCKpIaLhAFKcNGHXuvrQ ByKP8UR5uqerGL2EszikXmtfitUMQVbrR8EGVHr/d88cTMLmWnYhQy6DYcdVpW0hLorK gAZ2y71hdn7Zz9Q23HOlcIg9NDa7Y5c14TEvo4dqhVRNiPbnRaSBwruPEIBoMJ0sICUr 3vsJiQK7vp4zEoBbhHfEKsiw6qnT4Ka+DVfWRKs6CQFVk8uZGItZPQfrYHPAYQCvyfVC MI7QbAQLAI04W2ubNIt06qgnKCSGNppnMREqLOnQx5EV8w3clG5I9QECa/KBfBR6/llW Q6IA== X-Gm-Message-State: AOAM532M+YZEwBj71y7W7V2kiWQXgHdLNJ5JsyGba26EXPt8qPGxbps+ kGwgDIDBzkWhEMK64fkPjPo= X-Google-Smtp-Source: ABdhPJxxgIH6wsOVJPC6PHhvomZXBPhgkoYV37oH15/ETu5x8qujHd3DMfG6xLlWWUehw4NE3jiQ2w== X-Received: by 2002:a7b:cbda:: with SMTP id n26mr1372876wmi.93.1641889072077; Tue, 11 Jan 2022 00:17:52 -0800 (PST) Received: from 2a02-8388-e205-e880-569c-680a-c69b-a1ad.cable.dynamic.v6.surfer.at (2a02-8388-e205-e880-569c-680a-c69b-a1ad.cable.dynamic.v6.surfer.at. [2a02:8388:e205:e880:569c:680a:c69b:a1ad]) by smtp.gmail.com with ESMTPSA id d4sm6357729wri.91.2022.01.11.00.17.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jan 2022 00:17:51 -0800 (PST) Message-ID: <02f4b13397f1d77db433ffc0c9401a6e66fb706d.camel@gmail.com> Subject: Re: reordering of trapping operations and volatile From: Martin Uecker To: Richard Biener Cc: Andrew Pinski , "gcc@gcc.gnu.org" Date: Tue, 11 Jan 2022 09:17:50 +0100 In-Reply-To: References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> <40fd9a2f078cd6e87fedbc5f1e77baf8445a7356.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 08:17:54 -0000 Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener: > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote: > > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener: Hi Richard, > > > > For volatile, it seems this would need some tweaks. > > > > > > Yes, likewise when re-ordering (observable) traps like > > > > > > r = a / b; > > > q = c / d; > > > > I think this could also be useful. But at the moment I am > > concerned about the effect previous defined behavior > > being affected. For this, reordering traps is OK. Also > > sinking traps across observable behavior is OK. Just > > hoisting it up across observable behavior would > > be a problem. > > But in general that would apply to all UB. Consider > > int foo (int a, int b) > { > if (a < b) > return a + b; > bar (); > return a + b; > } > > we are happily hoisting a + b to the start of the function > but of course a + b can invoke UB. We consider that to > not matter because we eventually invoke this UB anyway. > Unless of course bar() does not return. Yes. > I realize that UB in a + b isn't (usually) observable but > UB resulting in traps are. Code motion for UB which then does not cause a change in observable behavior would still be ok. So my understanding is that you can not hoist a potentially trapping operation across a function call, but if it is UB which is implemented in way that just produces some random result but does not trap then this is ok. It would also be wrong if it affects the arguments for the function call. Here MSVC seems to do this: https://godbolt.org/z/8a8fTW8qP This seems incorect because if the call does not return there is no UB. I did not observe this with GCC or another compiler. > So I'm still wondering why you think that 'volatile' makes > a critical difference we ought to honor? I don't remember > 'volatile' being special in the definition of the abstract > machine with regarding to observability (as opposed to > sequence points). It is because it is used for I/O. Sequence points only matter for the semantics of the abstract machine, so according to "as-if" rule optimizers can do whatever they want as long as the observable behavior is the same "as-if" it followed the rules of the abstract machine. This observable behavior that needs to be preserved is defined as I/O and volatile accesses. The relevant part o the standard is this: "5.1.2.3 Program execution" paragraph 6 The least requirements on a conforming implementation are: — Accesses to volatile objects are evaluated strictly according to the rules of the abstract machine. — At program termination, all data written into files shall be identical to the result that execution of the program according to the abstract semantics would have produced. — The input and output dynamics of interactive devices shall take place as specified in 7.21.3. The intent of these requirements is that unbuffered or line-buffered output appear as soon as possible, to ensure that prompting messages actually appear prior to a program waiting for input. This is the observable behavior of the program." Martin > > > > I am trying to figure out whether this is feasible. > > > > > > For PRE yes, you'd just need to include the observable stmts you > > > care in the set of stmts that cause PRE to set BB_MAY_NOTRETURN. > > > In general this is of course harder. > > > > What other passes would need to be checked? > > All that do code motion by design or by accident. The difficulty is > that the resulting "wrong IL" is not wrong per se, just the difference is > which is hard to write a checker for (well, in priciple you could copy the > IL before passes and compare to the IL after) > > > And do you think there is any negative impact on > > an important optimization (considering this affects > > only volatile accesses)? > > Probably not. But then semantics of 'volatile' are very weak defined > so I'd like > to see a reference to a part of the standard that supports declaring this > (and only this - the 'volatile' case) a bug. > > > > > > GCC assumes by default that divide is trappable but stores not are not > > > > > observable. This is where -fnon-call-exceptions come into play. > > > > > > > > Ok, thanks! I will look at this! > > > > > > > > > In the second case, GCC assumes reducing trappable instructions are > > > > > fine. > > > > > > > > -fnon-call-exceptions would treat trapping instructions > > > > as defined (and trapping) instead of UB? This is > > > > then probably even stronger than the requirement above. > > > > > > No, I don't think it turns UB into defined behavior. Some frontends might > > > expect that to some extent. So even with -fnon-call-exceptions we'd > > > happily do the re-ordering unless the exception is catched in the same > > > function. > > > > Thanks, > > Martin > > > > > > > Note I thought -fno-delete-dead-exceptions would fix the sink > > > > > but it didn't. > > > > > > > > Martin > > > > > > > >