I think we should audit and fix usage of MYFLT2LRND and MYFLT2LONG.
Also, there are casts in sysdep.h to cast the output to int32.  I
wonder if that is necessary as the caller might want to cast to int or
long or what not and seems better to me to make that decision on the
calling side.

On Thu, Mar 23, 2017 at 7:50 AM, Stephen Kyne  wrote:
> Hi guys,
>
>
> For the no-pthread branch, I've been trying to get these macros running for
> MSVC. Originally there was some ASM code for the MSVC build but inline ASM
> is not allowed in 64bit builds so we needed an alternative.
>
>
> Luckily lrint was introduced in the C99 stuff introduced in VC2013 so we
> replaced it with that. However, it turns out the implementation is
> incredibly slow and profiling showed this. There are a few posts online on
> how to replace this with some intrinsic functions and this is my current
> stage. I've tested the code in isolation and it works as expected.
>
>
> The problem is the use of these macros is not really gelling well with how
> the intrinsic function works. It wants a reference to a float/double to work
> but sometimes r-values are passed into the macro which fails to compile.
>
>
> From looking at the usages of the macros, I'm seeing a lot of misuse and it
> seems the Linux/OSX variants are hiding this through the use of casts in the
> macro itself. The casts shouldn't really be there because they're slow and
> lrint is supposed to be fast / a way of avoiding casting.
>
>
> An example being "sfinfo.samplerate = (int) MYFLT2LRND((MYFLT)
> mixin[0].p->sr);", where "mixin[0].p->sr" is already an int.
>
>
> So i'd like to make changes to this macro (removing the casts for one thing)
> and make use of the type system to avoid misuse. Benefits should be
> correctness and performance increases.
>
>