From owner-freebsd-hackers@freebsd.org Mon Feb 26 04:40:30 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34798F296A0 for ; Mon, 26 Feb 2018 04:40:30 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic306-22.consmr.mail.ne1.yahoo.com (sonic306-22.consmr.mail.ne1.yahoo.com [66.163.189.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B0A6681FA3 for ; Mon, 26 Feb 2018 04:40:29 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: 4LNx12kVM1mHP9pCKQ8TyhCiJXtYHjpWwm4BdDaFW3lqULKF8SBu.xSDcJSD0P9 uGYHUJV.OuMjKaXl4.cE3ArQGLB0KDlSf924AZwRLWW_81rF6YUPpkQJ0JdcjZzW0K2iEAlIdL8i eUHzr8jtgaYURUBamCRRrDmwX98URrBYgcKIBNa3Bf_xKBBKTBASHZ57fb1gNDekAZRfMrLqTGky Tyby23MlI2ZumuFjv9XyNdzSCKzmH4T3YzD4ObyoR3QnDL86mmdDCQaVzOR48eT6WxVWs2.Oyx5d 5_w3SUyDMHMkyGKxcNuOT8Ip7xnARI53drsjGpNqRhiMCw4Vf9mFuE1gUPDl.XHEI1Rze6iHpWET kkIY9ghssbT2DkxReTqKvzDh9lZ4HS8JFbe4qJF6lPcmVzTtUI8haL0zEnk0SUb82hzYnYPlZmV7 05GgA6WXgZjtIBmFfiVgiFDL2jh8VoyxEIh3Xr7._ftDJydx4FusHnAl5CorgYnTWj2iUf4nX Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Mon, 26 Feb 2018 04:40:23 +0000 Received: from smtp230.mail.ne1.yahoo.com (EHLO [192.168.1.25]) ([10.218.253.211]) by smtp404.mail.ne1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID c920c595c0bc7ede23f066c3b2f36b8d; Mon, 26 Feb 2018 04:40:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Marking select(2) as restrict From: Mark Millard In-Reply-To: <20180226135457.B1203@besplex.bde.org> Date: Sun, 25 Feb 2018 20:40:16 -0800 Cc: Tijl Coosemans , FreeBSD Standards , FreeBSD Hackers , Kevin Lo Content-Transfer-Encoding: quoted-printable Message-Id: <1A2830F4-A00B-4C56-8D28-C46715DC7C9E@yahoo.com> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> <20180222105608.GE94212@kib.kiev.ua> <20180225214813.776a9f58@kalimero.tijl.coosemans.org> <2909E983-953A-4463-959C-F3C386BC6C9A@yahoo.com> <20180226135457.B1203@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 04:40:30 -0000 On 2018-Feb-25, at 7:45 PM, Bruce Evans wrote: > On Sun, 25 Feb 2018, Mark Millard via freebsd-standards wrote: >=20 >> On 2018-Feb-25, at 12:48 PM, Tijl Coosemans = wrote: >>=20 >>> On Thu, 22 Feb 2018 12:56:08 +0200 Konstantin Belousov wrote: >>>> Consider the recently changed devd code: >>>> select(n + 1, &fd, &fd, &fd); >>>> There, compiler can see that restrict is applied to arguments which = are >>>> given same values. Since this leads to the self-contradicting = statement >>>> fd !=3D fd >>>> which cannot be true, compliler in its optimizing wisdom can assume = that >>>> the code is never executing and remove it. I do not know whether = clang >>>> actually makes such transformation, but it does not sound = unfeasible >>>> looking at its other advances. >>>=20 >>> There's an example in the C99 standard that indicates such a call is = not >>> necessarily undefined so compilers cannot optimise it away: >>>=20 >>> EXAMPLE 3 >>> The function parameter declarations >>> void h(int n, int * restrict p, int * restrict q, int * restrict r) >>> { >>> int i; >>> for (i =3D 0; i < n; i++) >>> p[i] =3D q[i] + r[i]; >>> } >>> illustrate how an unmodified object can be aliased through two = restricted >>> pointers. In particular, if a and b are disjoint arrays, a call of = the >>> form h(100, a, b, b) has defined behavior, because array b is not = modified >>> within function h. >>=20 >> Good point. In essence the restrictions on the caller can >> not be known independently of how the parameters are used >> in the called code --something that prototype does not specify. >> This does constrain what the compiler can do about potential >> aliasing that it might detect. >>=20 >> A prototype that would make h's restrictions clearer is >> one that reports that q and r are not used to modify >> memory: >>=20 >> void h(int n, int * restrict p, int const * restrict q, int const * = restrict r); >>=20 >> With such a prototype, it is easier to known that q's "objects" >> and r's "objects" both simply must not overlap p's "objects". >> (See g from example 2 for its d+50 valid vs. d+1 invalid status.) >=20 > I think the example intentionally leaves out 'const'. I think const > already prevents aliasing. 'restrict' prevents it even more. Using > the combination in the exaple would make it less clear what the > 'restrict' part does. Agreed: the combination would make the example less clear about restrict. So, agreed: likely deliberate for specifying just restrict's semantics. I would not suggest my alternate h prototype for that example in the standard: different purposes served. > . . . restrict is not needed for the input-only > args since const suffices.=20 Here you lost me. With q and r having both the const and the restrict, updates to p's "objects" can not change the "object(s)" q and r validly can be used to access. That can be important. Without the "restrict" for q and r (but still having the const for each) it is valid for updates to p's "objects" to change what q and r then can validly access. The 2 restrict's in question do not seem redundant to me as far as the prototype goes. They may enable optimizations in some architectures: more order of operation independence so more reordering possible. A more general context could still require words describing requirements, words beyond the restrict and const use. I would not claim that adding const where it fits would make all contexts well described. This one just happened to be nicer for the person reading the prototype. (But it would makes for a worse specification of restrict of itself to have the const's in place in example 3.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late)