From owner-freebsd-toolchain@freebsd.org Mon Jun 5 10:03:33 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 6C690BFAF90 for ; Mon, 5 Jun 2017 10:03:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2C578386 for ; Mon, 5 Jun 2017 10:03:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4B8DABFAF8E; Mon, 5 Jun 2017 10:03:33 +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 4B044BFAF8D; Mon, 5 Jun 2017 10:03:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D924778380; Mon, 5 Jun 2017 10:03:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v55A3OQo070099 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Jun 2017 13:03:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v55A3OQo070099 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v55A3OCj070098; Mon, 5 Jun 2017 13:03:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Jun 2017 13:03:24 +0300 From: Konstantin Belousov To: Eric van Gyzen Cc: FreeBSD Hackers , toolchain@freebsd.org Subject: Re: Function attribute for optimization level Message-ID: <20170605100324.GV82323@kib.kiev.ua> References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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 10:03:33 -0000 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. > > I propose adding "__no_optimization" to sys/cdefs.h. The patch is > below. Empirical testing shows that clang 3.7 and later support > "optnone", and gcc 4.6 and later support "optimize()". Clang 3.4 does > not support either, so it takes the define-to-empty case. I did not > test clang 3.5 or 3.6. Where this attribute should be applied ? To the _thr_rtld_init() function ? > > Side note: GCC 4.6 with optimize(0) on amd64 emits two movq > instructions for memset(x,0,16), but GCC 5 emits a call to memset(). > > I have done no research to see if other popular codebases have such a > definition. If you know of one, please tell me; I would gladly adopt > an already common name for this proposal, for the sake of portability. > > Thanks in advance for your feedback. > > Eric > > > diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h index > 9cdc03c861cb..e370f6d6459e 100644 --- a/sys/sys/cdefs.h +++ > b/sys/sys/cdefs.h @@ -396,6 +396,14 @@ #define __unreachable() > ((void)0) #endif > > +#if __has_attribute(optnone) +#define __no_optimization > __attribute__((optnone)) +#elif __has_attribute(optimize) +#define > __no_optimization __attribute__((optimize(0))) +#else +#define > __no_optimization +#endif + /* XXX: should use `#if __STDC_VERSION__ < > 199901'. */ #if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER) > #define __func__ NULL _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Mon Jun 5 11:09:17 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 BA042BFC418 for ; Mon, 5 Jun 2017 11:09:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A0C8479CFB for ; Mon, 5 Jun 2017 11:09:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A00BCBFC416; Mon, 5 Jun 2017 11:09:17 +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 9D75FBFC415; Mon, 5 Jun 2017 11:09:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4251B79CF9; Mon, 5 Jun 2017 11:09:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v55B9BYn084494 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Jun 2017 14:09:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v55B9BYn084494 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v55B9BCN084493; Mon, 5 Jun 2017 14:09:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Jun 2017 14:09:11 +0300 From: Konstantin Belousov To: Eric van Gyzen Cc: FreeBSD Hackers , toolchain@freebsd.org Subject: Re: Function attribute for optimization level Message-ID: <20170605110911.GZ82323@kib.kiev.ua> References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> <20170605100324.GV82323@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170605100324.GV82323@kib.kiev.ua> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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 11:09:17 -0000 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. Then hopefully the __no_optimization hack is not needed. > > > > > I propose adding "__no_optimization" to sys/cdefs.h. The patch is > > below. Empirical testing shows that clang 3.7 and later support > > "optnone", and gcc 4.6 and later support "optimize()". Clang 3.4 does > > not support either, so it takes the define-to-empty case. I did not > > test clang 3.5 or 3.6. > Where this attribute should be applied ? To the _thr_rtld_init() function ? > > > > > Side note: GCC 4.6 with optimize(0) on amd64 emits two movq > > instructions for memset(x,0,16), but GCC 5 emits a call to memset(). > > > > I have done no research to see if other popular codebases have such a > > definition. If you know of one, please tell me; I would gladly adopt > > an already common name for this proposal, for the sake of portability. > > > > Thanks in advance for your feedback. > > > > Eric > > > > > > diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h index > > 9cdc03c861cb..e370f6d6459e 100644 --- a/sys/sys/cdefs.h +++ > > b/sys/sys/cdefs.h @@ -396,6 +396,14 @@ #define __unreachable() > > ((void)0) #endif > > > > +#if __has_attribute(optnone) +#define __no_optimization > > __attribute__((optnone)) +#elif __has_attribute(optimize) +#define > > __no_optimization __attribute__((optimize(0))) +#else +#define > > __no_optimization +#endif + /* XXX: should use `#if __STDC_VERSION__ < > > 199901'. */ #if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER) > > #define __func__ NULL _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Mon Jun 5 11:57:16 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 439F1BFD380 for ; Mon, 5 Jun 2017 11:57:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2AAFD7B810 for ; Mon, 5 Jun 2017 11:57:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 29F02BFD37E; Mon, 5 Jun 2017 11:57:16 +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 29521BFD37D; Mon, 5 Jun 2017 11:57:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D34DA7B80F; Mon, 5 Jun 2017 11:57:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::4075:b535:a8d3:d26] (unknown [IPv6:2001:470:7a58:0:4075:b535:a8d3:d26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8933919516; Mon, 5 Jun 2017 13:57:13 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C7C66C48-20D1-407B-AAF3-250460E3AE05"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Function attribute for optimization level Date: Mon, 5 Jun 2017 13:57:01 +0200 In-Reply-To: <20170605110911.GZ82323@kib.kiev.ua> Cc: Eric van Gyzen , FreeBSD Hackers , toolchain@freebsd.org To: Konstantin Belousov References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> <20170605100324.GV82323@kib.kiev.ua> <20170605110911.GZ82323@kib.kiev.ua> X-Mailer: Apple Mail (2.3273) 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 11:57:16 -0000 --Apple-Mail=_C7C66C48-20D1-407B-AAF3-250460E3AE05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 5 Jun 2017, at 13:09, 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. > > Then hopefully the __no_optimization hack is not needed. Like that, or use -fno-builtin: $ cat test-memcpy.c #include void foo(void) { long dummy = -1; memcpy(&dummy, &dummy, sizeof(dummy)); } $ cc -O2 -fno-builtin -fomit-frame-pointer -S test-memcpy.c -o - .text .file "test-memcpy.c" .globl foo # -- Begin function foo .p2align 4, 0x90 .type foo,@function foo: # @foo .cfi_startproc # BB#0: # %entry pushq %rax .Lcfi0: .cfi_def_cfa_offset 16 movq $-1, (%rsp) movq %rsp, %rdi movl $8, %edx movq %rdi, %rsi callq memcpy popq %rax retq .Lfunc_end0: .size foo, .Lfunc_end0-foo .cfi_endproc # -- End function .ident "FreeBSD clang version 5.0.0 (trunk 304659) (based on LLVM 5.0.0svn)" .section ".note.GNU-stack","",@progbits -Dimitry --Apple-Mail=_C7C66C48-20D1-407B-AAF3-250460E3AE05 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlk1RxkACgkQsF6jCi4glqMDUwCguMJgKivulhOfFPbolf5dyp4S xXwAoPqPmdS4cIYScjgzYk5BcaONt0X3 =Z2N/ -----END PGP SIGNATURE----- --Apple-Mail=_C7C66C48-20D1-407B-AAF3-250460E3AE05-- 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 From owner-freebsd-toolchain@freebsd.org Tue Jun 6 08:18:47 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 49983BF9ABE for ; Tue, 6 Jun 2017 08:18:47 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 30F6182CDF for ; Tue, 6 Jun 2017 08:18:47 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3028DBF9ABC; Tue, 6 Jun 2017 08:18:47 +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 2DC97BF9ABB; Tue, 6 Jun 2017 08:18:47 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 014FC82CDE; Tue, 6 Jun 2017 08:18:46 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host81-140-166-137.range81-140.btcentralplus.com [81.140.166.137]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id v568IVnn097686 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Jun 2017 08:18:35 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host host81-140-166-137.range81-140.btcentralplus.com [81.140.166.137] claimed to be [192.168.1.65] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Function attribute for optimization level From: David Chisnall In-Reply-To: <20170605195719.GA46606@stack.nl> Date: Tue, 6 Jun 2017 09:18:28 +0100 Cc: Konstantin Belousov , FreeBSD Hackers , Eric van Gyzen , toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2C01E322-CD6F-4BE6-B973-5B6C839DA5DE@FreeBSD.org> References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> <20170605100324.GV82323@kib.kiev.ua> <20170605110911.GZ82323@kib.kiev.ua> <20170605195719.GA46606@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.3273) 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: Tue, 06 Jun 2017 08:18:47 -0000 On 5 Jun 2017, at 20:57, Jilles Tjoelker wrote: >=20 > 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. In a non-freestanding environment, memcpy, memset, and memcmp calls are = both translated early to LLVM intrinsics and then have special handling = throughout the optimisation pipeline and in code generation. We=E2=80=99r= e likely to pay a noticeable penalty in code size and performance if we = don=E2=80=99t allow the compiler to do these, above and beyond the cost = of the call. David