From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) by sourceware.org (Postfix) with ESMTPS id DD9B2386EC3E for ; Sat, 8 Jan 2022 18:35:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DD9B2386EC3E Received: by mail-ua1-x931.google.com with SMTP id i5so16215573uaq.10 for ; Sat, 08 Jan 2022 10:35:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9vTc2M8Inrp9MYFoG9bzClwmcIo4OimI/lTK2j4+rdA=; b=CO4WxBBv/8S66Ae5N/4Q1LBG6pYIOuOO+XqrAITv2pgVeP7bOlkHmF3N5n0GnlZbzQ V7xILcPs1/yKCsncVcCXLr1eEWZ0ZUHm+9WDYAYe36zH3oS6XngASl+Ab328JEk5Z8Xj XI2MOnsy5M8738b60J9w3I7CYjn1+EgSCn7ugLxrBCD5+svMMSP9ayt/ZgC0eEO/ln9I Wc3rlTZfprj/UnWD+ZYlcUINOxKwzn78T3LY7qyLM5i/Ok2rYnuCZ24oW7+g6oDwHA7o rWRhQPpiw6HqV5ZwBF3Y5GqoeoMM3oT8km3G9x9AcWlCqBRczyvFn2CAtC8FhaucaDOQ 9fmA== X-Gm-Message-State: AOAM530up/ea6ywOz1lwWnv7yMa58Rq24TL7bwgNXJ7p+tyMgn8iW2Ib DJAl7Cct3JVdjaL31mwqyr4WwGS/LiUahLK+Pn0= X-Google-Smtp-Source: ABdhPJyIlA1AuBYCA4tizm1uSG8Ui7k6Lia9NzjL8pUFzpafmMjfqEhUGLAMpM3YBVIJu/ra7SblAh/9258ZPqS+nxo= X-Received: by 2002:a67:cd82:: with SMTP id r2mr22805669vsl.49.1641666958446; Sat, 08 Jan 2022 10:35:58 -0800 (PST) MIME-Version: 1.0 References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> In-Reply-To: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> From: Andrew Pinski Date: Sat, 8 Jan 2022 10:35:47 -0800 Message-ID: Subject: Re: reordering of trapping operations and volatile To: Martin Uecker Cc: "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 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: Sat, 08 Jan 2022 18:36:01 -0000 On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc wrote: > > > Hi Richard, > > I have a question regarding reodering of volatile > accesses and trapping operations. My initial > assumption (and hope) was that compilers take > care to avoid creating traps that are incorrectly > ordered relative to observable behavior. > > I had trouble finding examples, and my cursory > glace at the code seemed to confirm that GCC > carefully avoids this. But then someone showed > me this example, where this can happen in GCC: > > > volatile int x; > > int foo(int a, int b, _Bool store_to_x) > { > if (!store_to_x) > return a / b; > x = b; > return a / b; > } > > > https://godbolt.org/z/vq3r8vjxr The question becomes what is a trapping instruction vs an undefined instruction? For floating point types, it is well defined what is a trapping instruction while for integer types it is not well defined. On some (many?) targets dividing by 0 is just undefined and does not trap (powerpc, aarch64, arm and many others; MIPS it depends on the options passed to GCC if the conditional trap should be inserted or not). The other side is if there is undefined code on the path, should observable results happen first (stores to volatile/atomics, etc.)? GCC assumes by default that divide is trappable but stores not are not observable. This is where -fnon-call-exceptions come into play. In the second case, GCC assumes reducing trappable instructions are fine. Note I thought -fno-delete-dead-exceptions would fix the sink but it didn't. Thanks, Andrew Pinski > > In this example a division is hoisted > before the volatile store. (the division > by zero which could trap is UB, of course). > > As Martin Sebor pointed out this is done > as part of redundancy elimination > in tree-ssa-pre.c and that this might > simply be an oversight (and could then be > fixed with a small change). > > Could you clarify whether such reordering > is intentional and could be exploited in > general also in other optimizations or > confirm that this is an oversight that > affects only this specific case? > > If this is intentional, are there examples > where this is important for optimization? > > > Martin > > > > > >