From owner-freebsd-toolchain@freebsd.org Mon Jun 5 19:57:22 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B744AB794F2 for ; Mon, 5 Jun 2017 19:57:22 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A2AE467C91 for ; Mon, 5 Jun 2017 19:57:22 +0000 (UTC) (envelope-from jilles@stack.nl) Received: by mailman.ysv.freebsd.org (Postfix) id 9F13AB794F0; Mon, 5 Jun 2017 19:57:22 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CC0AB794EF; Mon, 5 Jun 2017 19:57:22 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 67B2867C90; Mon, 5 Jun 2017 19:57:22 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id A4E2D78; Mon, 5 Jun 2017 21:57:19 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 8D1A228497; Mon, 5 Jun 2017 21:57:19 +0200 (CEST) Date: Mon, 5 Jun 2017 21:57:19 +0200 From: Jilles Tjoelker To: Konstantin Belousov Cc: Eric van Gyzen , FreeBSD Hackers , toolchain@freebsd.org Subject: Re: Function attribute for optimization level Message-ID: <20170605195719.GA46606@stack.nl> References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> <20170605100324.GV82323@kib.kiev.ua> <20170605110911.GZ82323@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170605110911.GZ82323@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 19:57:22 -0000 On Mon, Jun 05, 2017 at 02:09:11PM +0300, Konstantin Belousov wrote: > On Mon, Jun 05, 2017 at 01:03:24PM +0300, Konstantin Belousov wrote: > > I think that toolchain@ is more suitable list for the discussion. > > On Sun, Jun 04, 2017 at 05:44:31PM -0500, Eric van Gyzen wrote: > > > _thr_rtld_init() calls memcpy() for the sole purpose of resolving its > > > PLT entry. With clang 4.0 and the current code, compiler optimization > > > defeats this attempt by completely eliding the call. Other compilers > > > or code might emit inline instructions instead of the library call, > > > also defeating the purpose. > > After looking more closely at the whole situation, I have a question > > that we probably must answer first. Is clang -ffreestanding mode > > broken ? memcpy(3) is not included into the set of the environment > > features required for a C11 freestanding implementation, and clang > > pretending that it knows the semantic of the call sounds broken. > Ok, I realized that I only added -ffreestanding to the rtld Makefile. > So clang is optimizing correctly there. Should we compile both libc > and libthr in the freestanding environment as well ? > I am sure that there are a lot of similar assumptions that libc and libthr > code calls into itself and not into the arbitrary re-implementation of > the same code as generated by modern compilers. I would prefer using -ffreestanding or -fno-builtin only for the files which need it. For example, builtin memcpy() with a small constant size is useful to read and write data regardless of alignment and type-based aliasing restrictions. If the memcpy() becomes an external call, both code size and speed will be affected and the programmer will probably choose some other way such as unsafe pointer casts or reading one byte at a time. I don't think it is possible to make this completely future-proof, though, since we don't have a lower layer in libc that implements a full C11 hosted environment and a higher layer that contains everything else. > Then hopefully the __no_optimization hack is not needed. Agreed, __no_optimization sounds more like a workaround for bugs in a specific compiler than something with a well-defined meaning across compilers. -- Jilles Tjoelker