From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 7D1783939C28 for ; Tue, 11 Jan 2022 20:01:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D1783939C28 Received: by mail-wr1-x432.google.com with SMTP id d19so360147wrb.0 for ; Tue, 11 Jan 2022 12:01:12 -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=fJ/m4BEzeTPrZdmB8tx8oRNgpL6dlNkqaO2dgot9L/k=; b=YlzoZ51pGk1+Getnn+GWCIOskEAof1OeYVku4wZqNw6XyebnrjZPhHrWtbSmT5WP1r CgNMxZn7+Q9eHnt/uHzf7uKfwHsi3g75D7V+kagOQpZb5rJVRfg0B1YGC9GfXDdOE3Ud InE+FBnebii1tmyeEw4pz0WZy4+V+kgrToYnt/v5M1/QTLDQMYOyXaBSUTfs3HguDZnv DyzMpEjM4o1x7Vi/u8SdqPbnWdNCNqxR00VpRzDvY27pV1MDOMnjiL8G5NJ9lV1k3rNT G63PY9qo+6WZKGvI/4mIBy5MzuSwZJ/AXgXKRUSTKH4FSKrVxsOKO6osTaD1s1hE2sLu W+NQ== X-Gm-Message-State: AOAM5336xJN18/2PlLREMbawUyucYGNzlx9BkQCNmb/DWU/kjFStoB1G QLVxZ2KhI7oWgsD4uhj1TqI= X-Google-Smtp-Source: ABdhPJzsFzGofMt9HBv3rQh/GempvEFAAsEGWPUSI58fxjtCLHUHmJ2d7LWBgH0R9xq7DUC/h3t/Dg== X-Received: by 2002:a5d:64a9:: with SMTP id m9mr5230324wrp.143.1641931271475; Tue, 11 Jan 2022 12:01:11 -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 m17sm2606997wmq.31.2022.01.11.12.01.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jan 2022 12:01:10 -0800 (PST) Message-ID: 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 21:01:09 +0100 In-Reply-To: References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> <40fd9a2f078cd6e87fedbc5f1e77baf8445a7356.camel@gmail.com> <02f4b13397f1d77db433ffc0c9401a6e66fb706d.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: 7bit 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 20:01:14 -0000 Am Dienstag, den 11.01.2022, 10:13 +0100 schrieb Richard Biener: > On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker wrote: > > 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: ... > Consider > > int a[1024]; > void foo (volatile int *p, float *q) > { > for (int i = 0; i < 1024; ++i) > { > *p = 1; > a[i] = *q; > } > } > > we happily apply invariant motion to the load from *q, making > it cross the store to the volatile object at *p. Now, q might be > NULL upon entry to the function and thus this transform > would violate the volatile "I/O" constraint (since I/O is observable) > and thus we will crash (which is UB) before doing the first I/O. > > That's an example I'd consider important for performance and > also a case that shows that usually the compiler will have a > very hard time proving UB cannot happen (as opposed to the > usual stance where it can assume it doesn't). I can see that the transformation in general is important, but why is it important if the "volatile" is there? I would assume that performance-sensitive code usually does not volatile. Or in other words, what is the purpose of volatile in this example if not either I/O or to prevent such optimizations? > The case we run into sth similar is with use of uninitialized > variables where proving some variable is initialized is nearly > impossible (copy initialization from a variable that is not > initialized is not initialization). These are the C++ rules. For C, an automatic variables which is not initialized and (as long as the address is not taken), it is directly UB. > We've mainly settled to the stance that only program termination > is observable which means if we do not know that a function > call will always return normally we have to avoid hoisting > observable UB across such function call (and I/O routines > usually fall into this category because they are not annotated > as always returning). Yes. > Handling all volatile accesses in the > very same way would be possible but quite some work I don't > see much value in. I see some value. But an alternative could be to remove volatile from the observable behavior in the standard or make it implementation-defined whether it is observable or not. Martin > Richard. > > > 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 > > > > > > > > > > > >