Re: [contribution] C11 threads implementation for Unix and Windows environments
On 20/02/17 07:49, Sebastian Huber wrote: > Hello Gokan, > > you may have a look at: > > https://svnweb.freebsd.org/base/head/lib/libstdthreads/ note that despite the looks this is non-portable and non-conforming implementation, it is way better than the posted github code, but it can still clobber errno, leak resources (and introduces cancellation points which may or may not be conforming depending how posix will integrate c11) as far as i'm aware the only c11 conforming open source implementation is the one in musl libc (and that's not portable to other libcs either).
Re: Improving code generation in the nvptx back end
On 02/17/2017 02:09 PM, Thomas Schwinge wrote: Hi! On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: [...] for "normal" functions there is no reason to use the ".param" space for passing arguments in and out of functions. We can then get rid of the boilerplate code to move ".param %in_ar*" into ".reg %ar*", and the other way round for "%value_out"/"%value". This will then also simplify the call sites, where all that code "evaporates". That's actually something I started to look into, many months ago, and I now just dug out those changes, and will post them later. (Very likely, the PTX "JIT" compiler will do the very same thing without difficulty, but why not directly generate code that is less verbose to read?) Using my WIP patch, the generated PTX code changes/is simplified as follows: It's probably a good idea to run cuobjdump -sass to see whether this has any effect at all. The most important issue that needs solving is probably still the old issue that ptxas isn't reliable. Looks like the llvm folks ran into the same problem, as I discovered last week: https://bugs.llvm.org//show_bug.cgi?id=27738 Bernd
Re: Improving code generation in the nvptx back end
On Fri, 17 Feb 2017, Thomas Schwinge wrote: > On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: > > [...] for "normal" functions there is no reason to use the > > ".param" space for passing arguments in and out of functions. We can > > then get rid of the boilerplate code to move ".param %in_ar*" into ".reg > > %ar*", and the other way round for "%value_out"/"%value". This will then > > also simplify the call sites, where all that code "evaporates". That's > > actually something I started to look into, many months ago, and I now > > just dug out those changes, and will post them later. > > > > (Very likely, the PTX "JIT" compiler will do the very same thing without > > difficulty, but why not directly generate code that is less verbose to > > read?) In general you cannot use this shorthand notation because PTX interop guidelines explicitly prescribe using the .param space for argument passing. See https://docs.nvidia.com/cuda/ptx-writers-guide-to-interoperability/ , section 3. So at best GCC can use it for calls where interop concerns are guaranteed to not arise: when the callee is not externally visible, and does not have its address taken. And there's a question of how well it's going to work after time passes, since other compilers always use the verbose form (and thus the .reg calling style is not frequently exercised). Alexander
Re: Obsolete powerpc*-*-*spe*
Hi David, > On Feb 17, 2017, at 01:10 , David Edelsohn wrote: > > This is not a new issue. The maintainer did not suddenly resign last > week. There have been numerous efforts to reach out to the SPE > community for over a *decade*, cajoling them to step up with > maintenance for the port. I am glad that this notice of obsolescence > has focused more attention on the long-standing problem. Would there be a minimum level of commitment you'd like to get to accept leaving the port in (if not this, at least that ...) ? Thanks, Olivier
