search for: perimeterinstitute

...tie breaking (away from zero). The question here is: Is this optimization worthwhile, or would it surprise too many people? Depending on this, it should either be disallowed, or possibly implemented for other back-ends as well. -erik -- Erik Schnetter <schnetter at cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130621/768d3be1/attachment.html>

...think that rint(x) = x + copysign(M,x) - copysign(M,x) where M is a magic number, and where the addition and subtraction cannot be optimized. I believe M=2^52. This should work fine at least for "reasonably small" numbers. -- Erik Schnetter <schnetter at cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130704/baf6fb07/attachment.html>

...sign(M,x) > > > where M is a magic number, and where the addition and subtraction > cannot be optimized. I believe M=2^52. This should work fine at > least for "reasonably small" numbers. > > -- > Erik Schnetter < schnetter at cct.lsu.edu > > http://www.perimeterinstitute.ca/personal/eschnetter/ -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

...nstructions are available. Support for x86_64 should be most complete (SSE2, AVX). Vecmathlib passes various correctness tests. I assume that many of its algorithms could stand improvement. I am still working on the documentation. -erik -- Erik Schnetter <schnetter at gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130205/f88f8f86/attachment.html>

...s of pointers and address spaces. Casting forth and back must preserve the address space. If I read the standard correctly, the OpenCL compiler may also compile functions several times, once for each combination of address spaces. -erik -- Erik Schnetter <schnetter at gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.

...pocl.sourceforge.net/ This announcement: http://pocl.sourceforge.net/pocl-0.8.html Change log: http://pocl.sourceforge.net/downloads/CHANGES Download: http://pocl.sourceforge.net/downloads The pocl developers August 2013 -- Erik Schnetter <schnetter at gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.

...ewinski > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- Erik Schnetter <schnetter at cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130209/156ef16d/attachment.html>

...there e.g. command line options, CPU attributes, or target triplets that would modify this? Or should this be filed as bug report? However, this may also be a bug in pocl as I haven't been able to reproduced this without pocl. -erik -- Erik Schnetter <schnetter at gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Si...

On May 23, 2013, at 10:37 AM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > In all fairness, I do not believe that ivdep is an ICC-specific pragma. There are many compilers that support ivdep and lots of legacy (and modern) codes that benefit from it. Seems silly, to me at least, to reinvent the wheel. Hi Cameron, The history of the idvep pragma is fascinating. I did not

On 08/07/2013 03:52 PM, Michele Scandale wrote: > > In the opencl specification is said that the four address spaces are > disjoint, so my conclusion of non aliasing with the others. In OpenCL 2.0, you can cast between the generic address space and global/local/private, so there's also that to consider.

Hi Justin, gentlemen, I'm afraid I have to escalate this issue at this point. Since it was discussed for the first time last summer, it was sufficient for us for a while to have lowering of math calls into intrinsics disabled at DragonEgg level, and link them against CUDA math functions at LLVM IR level. Now I can say: this is not sufficient any longer, and we need NVPTX backend to deal with

We already decide on a default. For these three targets is “whatever the user is running on.” For all the other targets it’s something the backend selects. I’m proposing we, as you say, remove the uncertainty and have the default always be the same from one run to the next even (especially) when those runs are on different machines. For X86, there’s two options, the “generic” target that backend