On Tue, Nov 04, 2014 at 10:20:53AM -0700, Jeff Law wrote: > On 11/04/14 09:11, Jakub Jelinek wrote: > > On Tue, Nov 04, 2014 at 07:41:42AM -0800, Steve Kargl wrote: > >> On Tue, Nov 04, 2014 at 03:34:43PM +0100, Bernd Schmidt wrote: > >>> The ptx port by its nature is lacking features that are expected on > >>> "normal" machines, such as alloca and indirect jumps. We have a subset > >>> of the C library which contains functions that can be implemented on the > >>> target (excluding things like file I/O other than printf which is a ptx > >>> builtin). > >>> > >>> It would be good to be able to also build as much of libgfortran as > >>> possible, and the following patch is what I've been using so far. It > >>> recognizes the target at configure time and restricts the list of > >>> compiled files, as well as providing a LIBGFOR_MINIMAL define for #ifdef > >>> tests. There's also a new file minimal.c which contains alternative > >>> implementations of some functionality (using printf to write error > >>> messages rather than fprintf and such). Constructors are currently > >>> unimplemented on ptx and therefore the init function is commented out. > >>> > >>> Comments on the approach, do the Fortran maintainers have a preference > >>> how this should look? The whole thing is good enough to substantially > >>> reduce the number of failures when trying to run the Fortran testsuites > >>> on nvptx (although many remain). > >>> > >> > >> It is unclear to me from reading the diff whether this patch > >> cause gfortran on ptx to knowingly violate the fortran standard. > >> If the answer is "yes, this patch causes gfortran on ptx to > >> violate the standard", then the patch is IMHO unacceptable. > > > > The point is, if the target can implement just a subset of the Fortran (or > > C or C++) standards, then ideally if you use anything that is not supported > > would just cause always host fallback, the code will still work, but will > > not be offloaded. So even supporting a subset of the standard is > > worthwhile, usually one will just offload the most performance critical > > parts of his code. > Also note there's a reasonable chance that the GPUs will continue to > evolve and will be able to support more of the standard language > features. Not sure if they'll ever do the IO side of Fortran, but they > could always surprise us. >
Thanks for the explanation. Certainly mapping Fortran's array syntax and many of the intrinsic subprograms to an accelerator may provide a nice speed improvement. It wasn't clear to me from Bernd original message that the patch was intended for OpenACC offloading. I was assuming that ptx was a new cpu architecture, which had limited capabilites. -- Steve
