how to enable vector intrinsic functions in fortran frontend

Tobias Burnus burnus@net-b.de
Mon Oct 15 19:05:00 GMT 2007


Tobias Schlüter wrote:
> Sa Liu wrote:
>> 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?
> The C frontend family went to great lengths to ensure that the vector
> stuff works reasonably well across platforms, so it might be worth
> looking there for inspiration.  I didn't find any mention of pixel in
> gcc's documentation, so they may have decided against it (which would
> also mean that you would have to implement the backend support for this).
I also would like that the vector types compile on (almost) any system.
The advantage of Fortran is that it is essentially system independent;
there are only very few parts in Fortran programs which are system
dependent (such as the arguments to the "SYSTEM" call).

VECTOR sounds like a concept very much suited to number crunching in
general and thus it makes sense - in terms of portability - that a
program targeted for a vector-supporting system also runs on systems
which do not; and even if the generated code on non-PowerPC is clumsy
and slow, having it supported there makes the feature more appealing to
scientific users (which rarely target one system only).

>> 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?
> I think an intrinsic module would be the best place for these to go.
The advantage of an intrinsic module would be that it keeps the
namespace clean; the disadvantage is that it is not directly compatible
with the XL Fortran compiler. For VEC_* this is indeed an option; for
the VECTOR(...) declaration, I fail to see how this is supposed to work.
Thus another option would be thus to use a flag - similar to
-fcray-pointer: Cray pointers are disabled by default, but get enabled
with this option. If the parser hits "VECTOR(...)" it should tell the
user that VECTOR is only supported with the such-and-such flag.
One could combine these: A flag to enable the VECTOR(...) declaration
and an intrinsic module to provide VEC_*. However, as VEC_* only takes
vectors, one could directly enable it with the -fvector-type flag. I
also do not see the problem name clashes for this reasons.

For the code organization:
- For intrinsics itself, grep e.g. for "lgamma" and look at the files
where it occurs
- For flag usage, maybe "grep flag_cray_pointer" gives some ideas
- For intrinsic modules, iso-c-binding.def and the places where it is
included might give some ideas. Maybe it also gives some ideas when
using no intrinsic module.

I also look forward to your contribution. (Some contribution in other
areas such as debugging symbols would also be welcome ;-) as gfortran
currently lacks people with with debugging-symbols knowledge.)

Greetings from Cologne to Böblingen(?),

Tobias



More information about the Fortran mailing list