RFC: Building a minimal libgfortran for nvptx

[Jeff Law]

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.

jeff