Date: Mon, 5 Jun 2017 21:57:19 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Eric van Gyzen <vangyzen@FreeBSD.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, toolchain@freebsd.org Subject: Re: Function attribute for optimization level Message-ID: <20170605195719.GA46606@stack.nl> In-Reply-To: <20170605110911.GZ82323@kib.kiev.ua> References: <85c47390-dd27-aa74-24fe-25a9a5352527@FreeBSD.org> <20170605100324.GV82323@kib.kiev.ua> <20170605110911.GZ82323@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170605195719.GA46606>