Hi! 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. Grüße, Thomas
pgphh8InAu2Ig.pgp
Description: PGP signature
