This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: how to enable vector intrinsic functions in fortran frontend


Sa Liu wrote:
> "Andrew Pinski" <pinskia@gmail.com> wrote on 17.10.2007 20:08:54:
> > The idea would allow:
> > 
> > vector(Integer, 16) :: a, b, c
>
> Thanks for pointing this out. I think we should support user specified 
> vector size for the generic vector type. 
> But I'm not quite sure about the syntax here. In C/C++ it is possible to 
> calculate number of units by vector_size/sizeof(scalar_type),
Well, gfortran offers also the vendor intrinsic function sizeof:

type t
  integer   :: i
  character :: c
end type t
integer(4) :: a
integer(8) :: b
type(t) :: myT
print *, sizeof(a),sizeof(b),sizeof(myT) ! prints: 4 8 8
end


> in Fortran we have to use Integer to represent char, short, int and long. Where could 
> I specify kind of scalar type? Somthing like vector(Integer(1), 16)?
>   
I'm not sure whether I understand the question. To express the integer
kind, Fortran has the syntax:
  Integer(kind=<n>),  Integer(<n>) or Integer*<n>
where <n> can be in gfortran 1, 2, 4, 8 or 16.
(Also initialization expression are possible, e.g. "Integer(constant)"
or "Integer(kind(an_integer_variable))".)

Using "Integer" without specifying a kind, implies the default kind
which is in gfortran "4" (or "8" using -fdefault-integer-8).

Thus "Vector(Integer(1), 16)" or "vector(Integer, 16)" (=
"vector(integer(4), 16)") make sense.


In another email you wrote:
> 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?
>   
I think this would be ok.

> Another question is, if no intrinsic module is used, where should the 
> VEC_* functions go?
Good question. Currently, the intrinsics themselves are defined in
intrinsic.c, their arguments are checked in check.c, they are simplified
in simplify.c and resolved in iresolve.c and the gimple is generated in
trans-intrinsic.c. (Not all intrinsics use all files and many share
functions.)

In principle, it would be nice to group all target-specific intrinsics
into a single file, such as intrinsics-vector.c or intrinisics-altivec.c
or ..., which would then either be compiled by itself or included
elsewhere (to use the functions available in the files).

One could use an #include mechanism, where different parts of that file
are included, but I don't know how messy this gets.

Intrinsic modules are actually not better: One needs to do essentially
the same, except that the functions only come available after "use
intrinsic_module_name" instead after specifying a flag.

> 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?
>   
I think this would be ok - as would be in principle using
add_functions() with if(flag) { "#include ..." }. The problem I see is
only how to do the argument checking or simplification or ... without
duplicating too many code (from e.g. check.c) and without adding target
specific stuff to all these files.

Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]