On Thu, Mar 20, 2014 at 12:38:49PM +0200, Riku Voipio <riku.voi...@linaro.org> wrote: > First part of the patch adds memory fence for aarch64. Strictly, this isn't > necessary, as the fallback to __atomic_thread_fence (__ATOMIC_SEQ_CST) > would output the same dmb ish instruction.
Thanks! We indeed plan to move the test for __atomic_thread_fence to earlier in the file, so it would become the default (are there any gcc versions that support aarch64 but not __atomic_thread_fence? I guess not). However, if aarch64 has some efficient load and store barriers, using them could be advantegous, i.e., if you have efficient implementations for the _ACQUIRE and _RELEASE variants, these could be quite useful. > Second part makes sure the ancient arm float format doesn't get used. As a historical sidenote, the ancient arm float fornmat is precisely the reason behind this, btw. :) However, we do have working code for both cases, and correctness beats speed, especially for these not-so-often used functions. I would prefer a massive #if statement for every useufl architeture out there and updating that over a negated one that breaks when double happens to be decimal ieee or somesuch bullshit that, in 20 years, might not be bullshit but the sane default. It's not as if new arm architectures will be introduced that often. > Alternative would be to drop all ancient arm float support - anyone still > using the abi wouldn't be upgrading to new libev. Well, I am sure old arm isn't the only platform with nonstandard fp (and I suspect future platforms might switch as well), so I would prefer a change that simply adds aarch64 to the list of "sane" architectures. Look at it that way: we also thought we had picked up all noteworthy architectures with our fences, but we regularly get patches :) -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev