search for: hboehm

...requires introducing dependencies on threading libraries, which are platform-specific (and may not even be available on some platforms) and will make you lose performance. So really I think the better solution is to modify the function signatures, even if it looks like more typing. [1] http://hboehm.info/boehm-hotpar11.pdf

...change? Thanks again, Hal ----- Original Message ----- > From: "Philip Reames via llvm-dev" <llvm-dev at lists.llvm.org> > To: "JF Bastien" <jfb at google.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Cc: "Hans Boehm" <hboehm at google.com> > Sent: Wednesday, January 13, 2016 11:45:35 AM > Subject: Re: [llvm-dev] RFC: non-temporal fencing in LLVM IR > On 01/12/2016 11:16 PM, JF Bastien wrote: > > Hello, fencing enthusiasts! > > > TL;DR: We'd like to propose an addition to the LLVM memo...

I agree with Tim's assessment for ARM. That's interesting; I wasn't previously aware of that instruction. My understanding is that Alpha would have the same problem for normal loads. I'm all in favor of more systematic handling of the fences associated with x86 non-temporal accesses. AFAICT, nontemporal loads and stores seem to have different fencing rules on x86, none of them

Hello, fencing enthusiasts! *TL;DR:* We'd like to propose an addition to the LLVM memory model requiring non-temporal accesses be surrounded by non-temporal load barriers and non-temporal store barriers, and we'd like to add such orderings to the fence IR opcode. We are open to different approaches, hence this email instead of a patch. *Who's "we"?* Philip Reames brought

Hello opus-dev, I've been cooking up this patchset to integrate NE10 library into opus. Current patchset focuses on encode use case mainly effecting performance of clt_mdct_forward() and opus_fft() (for float only) Glad to report the following on Encode use case: (Measured on my Beaglebone Black Cortex-A8 board) - Performance improvement for encode use case ~= 12.34% (Based on time -p