From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10536 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Model specific optimizations? Date: Thu, 29 Sep 2016 19:08:01 +0200 Message-ID: <20160929170801.GC22343@voyager> References: <20160929142126.GB22343@voyager> <20160929152354.GK19318@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1475168904 1684 195.159.176.226 (29 Sep 2016 17:08:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Sep 2016 17:08:24 +0000 (UTC) User-Agent: Mutt/1.5.23 (2014-03-12) To: musl@lists.openwall.com Original-X-From: musl-return-10549-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 29 19:08:21 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1bpeom-0008Ky-PG for gllmg-musl@m.gmane.org; Thu, 29 Sep 2016 19:08:20 +0200 Original-Received: (qmail 11540 invoked by uid 550); 29 Sep 2016 17:08:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 11519 invoked from network); 29 Sep 2016 17:08:20 -0000 Content-Disposition: inline In-Reply-To: <20160929152354.GK19318@brightrain.aerifal.cx> X-Provags-ID: V03:K0:DE7vIqywa8UMPmRnSz7Cor4gNp3lpkt3dG55/V8BrmZ33clpXrW Jkyb/jJ8oufo6CvX4BOEd/Lb0F5qj7/ScVypl+iPjHRERMtMDHP3S15VyqF2/h3cYKg5dMv TAjR1Q7k418BwVBycQGhzE6UTxyiOo8CfuAW6Y0EOFL9Mn3XjKEKZSXUytwN7AOX2JqaqrG JLzl5pCgxat8K3WkaQ9KA== X-UI-Out-Filterresults: notjunk:1;V01:K0:DZ+XaSnON/I=:inRksC31mkilr+cNeQFF6e MtqcEfqSWO4KVoFqI/I7Sqi+ysXno0jld+xNKXK2Vex28lViO2ZBpCqQ9IA8DlTs96HYWa5kj WE/ISEtVR39ljlT37R73OWGWAHjnzU/CwbHl/jrEc/kcWi9fuG7PgCTqqMfTrN1ggBGZsiLcg sRPtaC4PEvB/JB/adNQRA8LOHXyr55C9yGH/yCoR5ha+oVy1uO9kzVfraj6ok3GUlKFZ8Ajtq cPU9zfHfQzM8g/Fba/QFvCwo7mbexncY+PnNP8j3JRQFeujvVez/RwJMcQ5fjIAO6d+mjvQJq vgf13sIKJZE0ffaPbVdJOHMG73LweWFTuV772fI1za3rfsztKe5RF1OZyeBF9O4ewCki2tZf5 EkxUbYTzJpLv/RwjV9uaWRa8N/Zb2EOH6vpFxCAuxAAivkJ3WpWyLZo7H0OXSVx/JKrnPWdZW Wi/hKNjR3sO9rdEw9zC5uiUFBwhCdT80wiCXx0XMWegHxIWD/K/2L+Kz4hrNddEyZbt0I5E8l 4dO42XPBVIXWQDqDfYjt7nCqBB1OS86pEQ2AKNlfIQ89rYM4eo0nGXbFSfmYR8QdXIomGF3lp bnc8lW5Hocn5ipBJZr5kzT9L2AT28+0h7562WVtWx1/oBLPPZH+2F+oJwc99XHZJcvgh5N+ic aAlzfvXhLsTUNX054UwRgXqiX26QS+cBVkTF+iXh4PXCR7SuweyXvg8+w5iVDTT5MG/523rjq WN00gB9vg09CHZlL6ZEuRAR9pIYSVwhglyry+MYJkCik3GJKzuBqQkfiH2o= Xref: news.gmane.org gmane.linux.lib.musl.general:10536 Archived-At: On Thu, Sep 29, 2016 at 11:23:54AM -0400, Rich Felker wrote: > What kind of version-checking? Not all systems even give you a way to > version-check. > To the extent that they don't, they also don't give you a way to check for features (again, except for executing the instructions and seeing if you get SIGILL). PowerPC (sorry, but that's where I spent a lot of time on recently) for instance only has the PVR (Processor Version Register). No software I could find online uses another way to detect the features of the CPU. And for systems to not give you a way of detecting system version at runtime and then define optional parts of the ISA would be very dickish, in my opinion. That basically guarentees optional functions won't be used at all. > This code contains data races. In order to be safe under musl's memory > model, sqrtfn would have to be volatile and should probably be written > via a_cas_p. It also then has to have type void* and be cast to/from > function pointer type. See clock_gettime.c. > Well, yes, I was just throwing shit at a wall to see what sticks. We could also move the function pointer dispatch into a pthread_once block or something. I don't know if any caches need to be cleared then or not. But yes, there are better examples. > For some archs, gas produces an error or tags the .o file as needing a > certain ISA level if you use an instruction that's not present in the > baseline ISA. I'm not sure if this is an issue here or not. > As I said, fsqrt is defined in the baseline ISA, just marked as optional. So any PowerPC implementation is free to include it or not. There are a lot of optional features, and if the gas people made a different subarch for each combination of them, they'd be here all day. Not just instructions, too. Sometimes the optional thing is a register, and sometimes just bits in a register. > I think it's the #define sqrt soft_sqrt that's a hack. The inclusion > itself is okay and would be the right way to do this for sure if it > were just a compile-time check and not a runtime one. > I meant the define. While it is hacky, it does mean no code duplication and only one externally facing symbol regarding sqrt(), which is the one defined by the standard. Although I am abusing the little known rule about C that if a function is declared as static in its prototype, and the function definition doesn't have an explicit storage class specifier, then the function will be static. Most style guides (rightly) say to have the storage class specifier in the prototype and the definition be the same, because otherwise this gets confusing fast. I guess it goes to show that you should know your language even in the parts you barely ever use (because forbidden), because they might come in handy at some point. > Rich Ciao, Markus