From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by sourceware.org (Postfix) with ESMTPS id AAC663858C60 for ; Thu, 30 Nov 2023 12:50:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AAC663858C60 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 AAC663858C60 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::b33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701348655; cv=none; b=ahU1oNfZLAQ/4yIhu6JdcJ6nZeyzPJerM/XnFgzRRqlq2IJjNxLXi/MHchhLkoi5MDyK5vVTF+ypyQUcOalRjS6dm5Jjln7vnc2b7lsbig+oIiw+2A+uuK8g+jnrlgDknS9f2E8J3h4L3R5GKnqGELffD7lVeThU9iIPglkGUU0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701348655; c=relaxed/simple; bh=G4Xz/kgfSx02oCqXTNraRDPs7mu+JG5kjCD5F6b3eS8=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=fEHmsYhULLYwMoJJBYWJZJo6Naz0vgOafNmgdPfBlpzloK9z0vxSsQnjSoZIAUfhfyf1ynZizLNnpYC0WZjK3TfQWbnLZEcrWv5638jlFh/Ih2vihvFCqgeABLLCjggwwsTq4/zLT5+UHQDRYGiYIb4NnDOdAPWgv5N2yXhl+Lc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-db35caa1749so797351276.2 for ; Thu, 30 Nov 2023 04:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701348652; x=1701953452; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=95dEk6ANq5r1+UaReobS5a5llYh6Gwcse/SO3MXf1Qc=; b=HYTq4A/lrJyMrlaXKlMaO/tOOoWwRdOFW6PjTudCUPR9RE96UlZQshp7QngfvYIAdv z65j7Xr18XO8BobkJkUnvaRG2kRUkpulU+0fRdkJwYmeSz8DhSwnvl8Y2WM+i+woHlB8 Ph9+SSGgtNBGOJ6mMfbS/XXxfbz5r6ZFGxfEvhTIVnmHqwDGwSuvEISHNLHCzxQeTS4+ URHVJ1bsP6iQtJx9wI6TNLqjdQgfBIhjb6CxwB8IEwZj+Yeg9NtH2uI+tyj+KUPtOWxe vkxabF9jK/n/z/hr223OPU1rYB2Qhy11OsWy6m1Dxi98GQnB8yGxhQWqsZtqSccf7QYi QTEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701348652; x=1701953452; h=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=95dEk6ANq5r1+UaReobS5a5llYh6Gwcse/SO3MXf1Qc=; b=HMkHSGs5MkdnHDyPpSBhFKc9IHPRO4HTibTVDkh4ZfzfOiDimNzERT9M7YIcSKzDdM X+EtWAM51RniLi/PDpD2WK59mX3EchPPEwYiF42cBTvUNCfh7GUdZ6MegbDM5tsHDRWG tvjGn+0CDA0OXxsZ6E6HGk3fbTstOJ3hjmHAUo6qjGKWY3gwHvrAcSiT2q3rmwGrdZz3 gVp2XjThM8JnJKMPJg3UwZF7wlgODqebuFW/8sRCzAU/bbfs0Uw6lG01L6uWAMXOghR4 G67H4DfzWhpYMr6lJPKeQlo+SOQC9Rc0Sufi20Robpvy+osfMJozoM6hpYNIuQsU4Cww enmQ== X-Gm-Message-State: AOJu0Yx1mxaTJSjmqZOTtaNcK7UboT4PJz2zd9Yd444JWG+RiTwPDphr PpcBnMMGtxgomopD0nzLBW/2J/wsgBJE6mNo2q58BmNJBNI= X-Google-Smtp-Source: AGHT+IHtGL0EW+vAqEathbf1+Po8M41wO9K/tEXaML81nd+VMg724gWE/VQ55ObgmGxln5Ggkk3IvzgB3hTEb8QPPq8= X-Received: by 2002:a25:820b:0:b0:db0:2161:5950 with SMTP id q11-20020a25820b000000b00db021615950mr20198793ybk.63.1701348651931; Thu, 30 Nov 2023 04:50:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ties Klappe Date: Thu, 30 Nov 2023 13:50:15 +0100 Message-ID: Subject: Re: Unjustified optimization due to restricted struct members? To: Richard Biener Cc: gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000099d1b060b5e1a50" X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,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: --000000000000099d1b060b5e1a50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Richard. Similar to the struct example, I was also wondering about why the following code does *not* get optimized (e.g. https://godbolt.org/z/9eGrjjK81): int f(int* restrict a[restrict 2]) { *(a[0]) =3D 10; *(a[1]) =3D 11; return *(a[0]); } Do you happen to know why a reload via a[0] is required? I would have expected to see the same optimization as is performed for the struct example. Kind regards, Ties Op do 30 nov 2023 om 13:16 schreef Richard Biener < richard.guenther@gmail.com>: > On Thu, Nov 30, 2023 at 12:07=E2=80=AFPM Ties Klappe via Gcc > wrote: > > > > When reading section 6.7.3.1 of the C standard (quoted below) about > > the *restrict > > *type qualifier, the first section talks about *ordinary identifiers*. > > These are defined in section 6.2.3, and exclude members of structures. > > > > Let D be a declaration of an ordinary identifier that provides a means = of > > > designating an object P as a restrict-qualified pointer to type T. > > > > > > I would assume that this means that in the code excerpt below the > function > > *h* cannot be optimized by substituting the load of *b.p *for *10*, as > the > > standard does not specify what it means for a struct member to be > restrict > > qualified. However, the code is still optimized by gcc (but not Clang), > as > > can be seen here: https://godbolt.org/z/hEnKKoaae > > > > struct bar { > > int* restrict p; > > int* restrict q; > > }; > > > > int h(struct bar b) { > > *b.p =3D 10; > > *b.q =3D 11; > > return *b.p; > > } > > > > Was this a deliberate choice, or does it simply follow from how restrict > is > > supported in gcc (and could this be considered a bug w.r.t. the > standard)? > > Hmm, this was a deliberate choice (it also works for global 'b'), I didn't > think > the standard would exclude that. Note GCCs C++ standard library makes > use of restrict qualified pointers as structure members for example. > > Richard. > --000000000000099d1b060b5e1a50--