Date: Tue, 27 Apr 2010 09:04:51 +0200 From: Roman Divacky <rdivacky@FreeBSD.org> To: Andrew Reilly <areilly@bigpond.net.au> Cc: freebsd-multimedia@FreeBSD.org, Alexander Best <alexbestms@wwu.de>, freebsd-current@FreeBSD.org Subject: Re: [CFT]: ClangBSD is selfhosting, we need testers now Message-ID: <20100427070451.GA16910@freebsd.org> In-Reply-To: <20100427045053.GA64971@duncan.reilly.home> References: <20100424080533.GA77435@freebsd.org> <permail-20100425100649f0889e8400006eb9-a_best01@message-id.uni-muenster.de> <20100427045053.GA64971@duncan.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
while I agree that the function is strange there indeed is a bug in llvm. See: http://llvm.org/bugs/show_bug.cgi?id=6941 On Tue, Apr 27, 2010 at 02:50:53PM +1000, Andrew Reilly wrote: > On Sun, Apr 25, 2010 at 12:06:49PM +0200, Alexander Best wrote: > > i was able to pinpoint the > > exact function which is causing the problem: > > > > it's snd_xbytes(). > > This is an odd-looking function. Its purpose is to compute the > size of a target buffer for a block of audio samples that might > be sample-rate-converted or format changed. It has a loop to > compute the gcd of the second two arguments (from, to), so that > it can divide by that common factor so that it can then do v * > (to/x) / (from/x). It's not immediately obvious to me why it > bothers to find the gcd, since the division by the original > from should work anyway, as it's using a 64-bit numerator... > > The only difference that I can see when this is compiled with cc > vs clang on my amd64 system is that the latter uses a divq in > the loop and the former uses a divl. I haven't figured out why, > yet. Hmm. If the same division logic is being used in the i386 > version of clang, then it's possible that this is resulting in > a call to an extended precision divide subroutine, which could > slow things down a bit. > > Cheers, > > -- > Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100427070451.GA16910>