From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id 5786E3858C3A for ; Tue, 13 Feb 2024 14:16:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5786E3858C3A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5786E3858C3A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::230 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707833774; cv=none; b=kVikzC9GXsNjdDq/DNAHPGo7HTfZbk8tQAoiW7V6B2tYeLR2dlWxRGeWv9JdOBBHs9tNt5cH+tPySlcKXmJxiHS/P6dT214kWWJWRirjtZDeCvv2U0xMHLOFIboS3sSfOWXV6qgDlxqKNR5525f1bB8i0H5wxA8AJ5QkCUWB1pc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707833774; c=relaxed/simple; bh=0Uh13LVGy/98Vlv7iFDoUwTzdkSwnUvlPIRP6SCUSOo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Vf84GA/sQVPP4uJQWuB9/Pk7lv8SGkQtv7r9rIaMXpAnDhcdCNw95IZYq7v6hh8oROJ7Ydw/bleWQlyBbdGyTmHRYW5dn1voyCvV5fqlrGl1+303KE+po3qREqnzzMcd5vpoeV5Xze8qhBjlOiSOHok8dJZa/w30GCGqvMh0PWo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2d0bc402c8eso44138281fa.1 for ; Tue, 13 Feb 2024 06:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707833770; x=1708438570; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=c0PItz7WFth3jiYjYTKmfuO/YFXn6Cf+og/XBWBQF0c=; b=lhgB1Xoo5wjTOUV+7pgZXxDmz8qyn6f6uH2BXk3fKotuQsdB3AlVTaSTLaHBHKBJOF mh+4mC5WgfVf4Eixgl4EdB6TeRNymcqS5Hiuuiw7lqI0ZTjxYFl0TyQ7JzTy4a8rj1Nf vLQkHnVsJMnQakv6k5wS5oWjrn/j2pr18byWwDkyZY4gR5aDDcDZOVyX4Yac0EOIPKUY WCzC3uiCeLW1hEsmBoZlMc9nX1AjkKbmvZwLUKzexffRH8u/e4znygJy8s4bPYzI7OTZ KyMSQB8eVAuawZuqCJOz+NO2L4D/Bu7goT+iW6oIi5vqs3MeRQg6obqt7s1vH9kCd4/d URKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707833770; x=1708438570; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c0PItz7WFth3jiYjYTKmfuO/YFXn6Cf+og/XBWBQF0c=; b=KwRwAqPimrjfteHtsrK1DqGpciywlshvpXBLob9a+bV8s73lqDaTIw60wT4gyiy9Lt JAAutLLUXsDqXjC0IyC2VRY7RySj7Rg5ISvQQc62u2Cr9c8SgsCzTOwmv9MXjkmGcRiF ubjAUYPeCxsv7fKHK86m62E6bbnsYAY1BbKcK8DfvmMucpC/AkevHSq0qi/SzXxTt6n9 vuWLfT6WVIiCSJd+gG+0Oxv8ijwKgOl/YKrJ7Vmxgo2oMg7Zte1BtBzBHwR6LaucUlrw VRNukMpqlKKxpJwhZ5cRE4DLxXvzA9cqbUMz7D/Hb2BpL1fho1FUM88RznyDeja2k4En 3NHg== X-Gm-Message-State: AOJu0YzIzCPrH8kJ71UA+RuMSBhT4cXdte/GMdANvROv9xnri3WDGkG5 4cSvOyZJSm7vu9f92zsi+4zAsZILaYcdVz2agT8xwxSFgzJP6QjIOFS3acb//vC74i/AZ3L0IjO Y99Rg87WsTvKUOG6wL33Gso3dJ+A= X-Google-Smtp-Source: AGHT+IGxrZY8dD8tiIRS4iVDHK5oXwWP/HvBvwZ9u+NMhOiDGsJMmkbkQqImQlRNeq5ltwILlujefTjh1cxOMy2iyoc= X-Received: by 2002:a2e:bb85:0:b0:2d0:a6bc:aa11 with SMTP id y5-20020a2ebb85000000b002d0a6bcaa11mr835871lje.9.1707833769371; Tue, 13 Feb 2024 06:16:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Tue, 13 Feb 2024 15:15:58 +0100 Message-ID: Subject: Re: Nested restrict pointers: missed optimization & client with UB? To: Ties Klappe Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 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,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 List-Id: On Tue, Feb 13, 2024 at 2:02=E2=80=AFPM Ties Klappe via Gcc wrote: > > Hi, > > I have two questions related to nested restrict pointers. > GCC 13.02 with optimization level 3 optimizes the function *foo1* to simp= ly > return 10. > > int foo1(int *restrict *restrict p, int *restrict *restrict q) > { > **p =3D 10; > **q =3D 11; > return **p; > } > > I am curious why the function *foo2* is not optimized in the same way (se= e > https://godbolt.org/z/E4cx1c1GP): the first pointer dereference of p and = q > result in the restrict qualified pointer lvalues, which are used to write > to a disjoint (as promised by the restrict qualifier) location storing an > integer object. So this should give enough information to perform the > optimization, i.e. a write via **q cannot change the object **p designate= s > if the program has defined behavior. > > int foo2(int *restrict *p, int *restrict *q) > { > **p =3D 10; > **q =3D 11; this function could do int a; *p =3D &a; **q =3D 11; **p =3D 12; > return **q; even when being called as you outline below. > } > > Secondly, if we would have a client *main* invoking *foo1* (see below), t= he > optimization would be incorrect if the client does not contain undefined > behavior. So I am curious how the standard section 6.7.3.1 actually appli= es > here: if the program is defined, I would assume both lvalues *p and *q ar= e > said to be based on xp (xp =3D *p =3D *q; =3D object `*P` *where the stan= dard > refers to), but is it actually the case that both the *p and *q expressio= ns > are based on the same object P? > > int main() { > int x =3D 0; > int* xp =3D &x; > > int res =3D foo1(&xp, &xp); > > return 0; > } > > So to wrap up, I have two questions: > > 1. Should *foo2* be optimized in the same way as *foo1* and is it simply = a > missed optimization candidate, or is there another reason GCC does not > optimize it? > 2. Does the client *main* contain undefined behavior according to GCC, an= d > if so, why? > > Thank you in advance. We are optimizing the following which is related at least to the amount of memory references done. I'm also curious how the standard reads here. Implementation-wise it's a bit difficult to handle the int ** restrict case, as points-to analysis has to handle *p and *q to point to an object as if p and q themselves were restrict. I'm not sure that doesn't open up things for miscompiles. int * restrict p; int * restrict q; int foo2() { *p =3D 10; *q =3D 11; return *p; } int main () { int x =3D 0; int* xp =3D &x; p =3D xp; q =3D xp; int res =3D foo1(); return 0; } Richard. > Kind regards, > Ties