On Mon, Apr 28, 2014 at 07:47:13PM +0200, Thomas Schwinge wrote:
> While working on some OpenACC constructs in the C front end (notably
> those tagged as »Executable Directives«, OpenACC 2.0, 2.12), Jim has
> noticed that for a certain class of OpenMP constructs (corresponding in
> "style" to the OpenACC Executable Directives), these are directly lowered
> to builtin function calls in the front ends, instead of creating trivial
> tree nodes, and passing these nodes through all the following compiler
> infrastructure, unaltered. These are, for example,
> gcc/c-family/c-omp:c_finish_omp_barrier, or
> gcc/c/c-typeck.c:c_finish_omp_cancel. The same is done in the Fortran
> front end, for example, fortran/trans-openmp.c:gfc_trans_omp_barrier.
> Such Open* constructs semantically map to runtime library function calls,
> without needing any, say, variable remapping in structured blocks
> attached to the constructs, for example.
>
> When contributing their OpenACC Fortran front end work to the
> gomp-4_0-branch, Samsung, on the other hand, have added new tree nodes,
> such as OACC_WAIT, which then are to be translated into runtime library
> calls in the omp-low.c's expansion routines. (I'm not criticizing that;
> it's of course a sensible thing to do, to handle all Open* constructs the
> same way.)
>
> We now wonder which style is to prefer? Lowering early into builtin
> function calls reduces the number of required tree node codes as well as
> some boiler-plate code in the middle end, but potentially adds code
> duplication in several front ends (and possibly elsewhere in the middle
> end code, too) for building argument lists for runtime library calls, and
> so on, which is avoided by centralizing all the library function calls in
> one place, in omp-low.c's expansion routines.
Depends. The reason we lower some constructs immediately is that the
middle-end either doesn't care about them at all, or only minimally, and the
code to generate the builtin calls in the frontends is smaller than the
amount of code that would be needed to support the extra tree AND gimple
code, often by significant amount.
Even taskgroup construct initially has been just lowered to 2 function calls
in the FEs, but then I found I need to treat it as a region for cancellation
diagnostics in the middle-end, which is why it is a tree/gimple code now.
So, I'd suggest if you don't need new tree/gimple codes and the lowering in
FEs is sufficiently small to lower early, if you need it during
gimplification, cfg creation, omp lowering or expansion, consider
tree/gimple codes.
Jakub
