This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

OpenMP: Lowering to builtin function calls in the front ends, instead of creating trivial tree nodes?


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

Attachment: pgpIa_JEwLWHq.pgp
Description: PGP signature


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