Re: how to enable vector intrinsic functions in fortran frontend

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Mon, Oct 15, 2007 at 08:01:53PM +0200, Sa Liu wrote:
> Hi,
> 
> The IBM XL Fortran compiler (XL Fortran V11.1 for Linux) defines vector 
> data types ( 
> http://publib.boulder.ibm.com/infocenter/lnxpcomp/v9v111/topic/com.ibm.xlf111.linux.doc/xlflr/vectordatatype.htm#vectordatatype 
> ), in order to enable PowerPC VMX intrinsic procedures in Fortran 
> (http://publib.boulder.ibm.com/infocenter/lnxpcomp/v9v111/topic/com.ibm.xlf111.linux.doc/xlflr/vmxintrinsics.htm#vmxintrinsics). 
> We are now going to port the same feature to gfortran. In addition we 
> would like to enable the vector intrinsics on SPU too. But there are still 
> a couple of questions need to be clarified.
> 
> Since PowerPC Vector type can be composed of different scalar types, some 
> of which, like pixel type doesn't exist in Fortran. XLF defines pixel type 
> in compiler frontend, but restricts its usage only as part of a vector 
> type. Our proposal is to have a facility in Fortran frontend to add 
> backend-specific data types, and construct vector and it's special scalar 
> types/kinds in PowerPC/SPU backend. Does this sound reasonable?
> 
> As to the intrinsic functions, the target specific builtin functions (e.g. 
> __builtin_altivec_...) have been initialized in 
> gfc_init_builtin_functions. The question is how could these functions be 
> mapped to Fortran frontend, with names recognizable by the fortran 
> program?
> 
> Any opinion on this will be appreciated... 
> 

This is my humble opinion and should not be construed to be
a position of the gfortran maintainers nor be taken as a 
death sentence to any potential patch.

I personally do not think adding vendor specific extensions into
the Fortran FE is desirable (with the possible exception for g77
compatibility).  This opens up a potential nightmare for future
maintenance and the request from every other vendor to include 
their pet extensions (e.g., RECORD and STRUCTURE from Digital, 
and yes I know Digital no longer exists).  In fact, gfortran 
isn't even a conforming Fortran 95 compiler, yet.  Developers
and gfortran maintainers should be concentrating on implementing
and maintaining a standard conforming Fortran compiler (both F95
and F2003).  g77 fell into a quagmire of questionable feature
creep and de facto extensions.  I have no desire to see gfortran
end up in the same state as g77.

Before anyone raises the question about my support for Asher's
work on Cray pointers, I'll kindly remind people that prior to
F90/95 and more recently ISO C bindings, Cray pointers were the only
solution for a select set of problems in Fortran.  The fact that
many, if not most, commercial vendors supported Cray pointers
also weighed heavily in favor of support for its inclusion.

With consideration of GCC structure, it would seem to me that
contributing target specific code to the tree-vectorizer feature
in the middle-/back-end is much more desirable.  That is, all
languages supported by GCC could benefit.  Yes, I realize that
this doesn't directly aid in dealing with XLF specific language
statements.

Again, the above is just my opinion.

Now, if you proceed with a patch, please 
1) hide everything behind a -fXLF-vector or similar option.
2) include adequate documentation withn the code via comments and
   documentation in gfortran.info.
3) provide a comprehensive set of testcases to testsuite/gfortran.dg.
   (These must already exist for testing XLF).
and
4) provide continuing support for any and FORALL future bug reports
   related to this feature.

-- 
Steve