This is the mail archive of the
mailing list for the GNU Fortran project.
Re: how to enable vector intrinsic functions in fortran frontend
- From: Sa Liu <SALIU at de dot ibm dot com>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: fortran at gcc dot gnu dot org, Steve Kargl <sgk at troutmask dot apl dot washington dot edu>, Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- Date: Mon, 22 Oct 2007 16:57:21 +0200
- Subject: Re: how to enable vector intrinsic functions in fortran frontend
Tobias Burnus <email@example.com> wrote on 17.10.2007 19:25:26:
> This has two disadvantage, a small one and a large one. The small one
> is: xlf does not require the user to insert "use ..." before (s)he can
> use VECTOR/VEC_*. And there is a large disadvantage: VECTOR(...) is not
> a user-defined TYPE (= struct, or approx. class), procedure or a module
> variable. It is a new syntax and can therefore not be represented as
> module. Thus you need in any case a flag for VECTOR(...).
> For theVEC_* you can use an intrinsic module, but I actually do not see
> any advantage of doing so as one needs the flag in any case.
Thank you a lot for the explanation and I agree that we perhaps should use
flags to avoid the incompatibility with XLF. But I still don't think we
can control both the generic vector type and the target specific
intrinsics by one flag. Would it be reasonable to have an option
-fvector-type to allow declaration of vector types, and a target option
-maltivec to enable the VMX intrinsics, as well as another one, say
-mspu-intrinsics for those on SPU?
Another question is, if no intrinsic module is used, where should the
VEC_* functions go? I thought of adding them to the gfc namespace by a
function, say add_vmx_intrinsics, which does the similar work as
add_functions does in intrinsic.c. Is this somthing that Fortran frontend
would accept? Any better ideas to avoid mixing up Fortran generic stuff
and target specific functions?