Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 19 Mar 2017 11:05:22 -0400
From: Rich Felker <>
Subject: Re: [PATCH] aarch64: add single instruction math functions

On Sun, Mar 19, 2017 at 08:55:58AM -0400, David Edelsohn wrote:
> I thought that the goal of musl was "Minimal machine-specific code".

My interpretation of minimal is two-fold:

- minimal amount of arch-specific coding required to bring up a new

- when arch-specific code is present by necessity or for optimization
  (speed or size), keeping complexity, maintenance cost, and room for
  arch-specific bugs minimal.

This is not intended to preclude use of single-instruction primitives
(see existing code for x86, etc.) for math functions or even critical
things that may be somewhat more complex like memcpy.

> Does musl want to start a new arms race?

What I call an arms race is perpetually adding new, often
runtime-selected, vectorized memcpy variants for every new vector isa
level, often with costly tradeoffs (like greatly increasing context
switch time) and no empirical evidence to justify them on a
system-wide scale, just benchmarks tailored to get the results the
author of the asm wants. That kind of stuff is not appropriate for

Ideally we'll eventually be able to rely on compilers just generating
the optimal code for memcpy from a trivial one-line C version. We're
not there yet. But I don't even have such hope for the future with
math. It's highly nontrivial for a compiler to establish that complex
code with multiple levels of branches is equivalent to a single ieee
operation that the isa implements.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.