ffc team mailing list archive

[Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx>]

On 25 February 2013 17:07, Florian Rathgeber
<florian.rathgeber@xxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> FFC generates C++ code, which makes sense given that the UFC interface
> is specified in C++. It is however a limitation when you want to use
> FFC to generate code for another interface/backend, as we do with
> PyOP2 (see our branch https://code.launchpad.net/~mapdes/ffc/pyop2).
>
> We require all kernels (and by kernels I mean basically every UFC
> function that is generated e.g. tabulate_tensor) to be C99 for a
> number of reasons - which are not relevant for this discussion but
> I'll mention some of them for those who are curious:
>
> 1) We target multiple hardware architectures (CUDA and OpenCL among
> others), which have limited support for C++. We want to keep the door
> open for more architectures in the future and the lowest common
> denominator will likely remain to be C.
>
> 2) We rely on pycparser to be able to parse kernels for
> instrumentations s.a. adding memory space attributes for OpenCL. To
> the best of our knowledge there's no reliable and easy to use C++
> parser available in Python.
>
> It turns out that FFC generated code is in fact C99, apart from:
>
> a) Usage of functions like sqrt, abs, pow from the std namespace.
>
> b) Usage of C++ exceptions (only when hitting invalid orientation
> markers).
>
> c) Usage of the static keyword (which has a different meaning in C99).
>
> So far we have overcome this issue by specializing those code snippets
> we were using and which had C99 incompatible code in them. It seems
> this is not a very elegant nor maintainable solution.
>
> At the moment FFC isn't quite set up for adding another code
> generation backend that generates C99 code without introducing lots of
> special cases. So my questions are:

The idea is that code formatting for C++ is handled by the module
cpp.py which implements the format dictionary.
To generate code for a different target language, you should implement
a new format dictionary in c.py (or fortran.py).
Then in modules like codegeneration.py where we currently do:

from ffc.cpp import format, indent

the import shold be depending on the target language.
At least, that's how the design was intended.
However, as C++ has been the only target language available in FFC
since the beginning, the concept has never been tested and there are
probably many cases, like the above, which are C++ spefic.

The above approach would be the _correct_ way as I see it, but might
require a bit of work initially. However, I think it will worthwhile
in the end, particularly if you want to merge your code back into FFC.

Kristian

> 1) Is there value in restructuring FFC to better accommodate adding
> code generation backends which do not target UFC? If so, where do we
> start? You're welcome to look at how we're doing it at the moment,
> which is an attempt to minimize changes to existing code and the FFC
> pipeline and clearly not very elegant.
>
> 2) Is there an easier way of generating C kernels given the
> constraints a-c we've identified above?
>
> These questions are related but I think could be treated separately. I
> can think of a few options for 2):
>
> i) Add using declarations to the UFC kernel templates in ufc_utils and
> drop the std:: prefix in the function bodies. This would (mostly)
> allow functions bodies to remain C99 compatible.
>
> ii) Add Python string templates to the code snippets allowing to
> choose between C++ and C99 specific statements where necessary and
> depending on the code generation target i.e. replace "std::sqrt" by
> "%(sqrt)s" and then replace that template depending
>
> I think ii) is more flexible but more "messy" but i) alone might be
> too limiting and a combination of both might be required.
>
> In our branch we have taken great care to make sure we pass all tests
> and don't break any UFC/DOLFIN functionality and we plan to add
> additional tests exercising the pyop2 code generation backend. We'd
> like to propose our branch for merging into the FFC trunk in the near
> future and are therefore very keen on any ideas how to overcome the
> issues I outlined and any comments and suggestions on the changes we
> propose.
>
> Florian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlErjFgACgkQ8Z6llsctAxYZIACg5N+c9uxeWwEoJ1x8SSy2rKHo
> z/8AoMwa9cAwQwWeGEUi86g/Eilf/ms9
> =E3VL
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ffc
> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ffc
> More help   : https://help.launchpad.net/ListHelp
>