This patch series lays some groundwork for the project to redo the OpenACC "kernels" region support in GCC, described in Thomas Schwinge's recent talk at the GNU Cauldron:
https://gcc.gnu.org/wiki/cauldron2019talks?action=AttachFile&do=view&target=OpenACC+kernels-cauldron2019.pdf Briefly, the larger goal is to make the compiler recognize "for" loops that are candidates for parallelization, and treat them as if they were annotated with "#pragma acc loop auto". This is fairly straightforward to do on the output of the Fortran and C++ front ends, which both produce a high-level parse tree representation of the loop. OTOH, the C front end currently lowers loops into a goto form very early, making it hard both to recognize "for" loops and to differentiate between (valid) structured and (invalid) unstructured control flow in the body of the loop. So, the immediate goal of this patch sequence is to make the C front end produce output using the same high-level tree representation as the C++ front end already emits: specifically, to produce FOR_STMT, WHILE_STMT, and DO_STMT for loops, BREAK_STMT and CONTINUE_STMT instead of gotos, and also SWITCH_STMT instead of SWITCH_EXPR since that's mixed up in the handling for "break". Besides this being helpful to OpenACC implementation, there's also some argument to be made that sharing more code between the respective C family front ends is good from an engineering perspective, etc. Part 1 of the patch set moves the definitions and support (genericization, pretty-printers, dumpers, etc) for those tree nodes out of the cp/ front end and into the common c-family/ code. Part 2 hacks up the C front end to emit the now-shared data structures. I bootstrapped and regression-tested this on x86_64-linux-gnu. There are a few regressions involving these tests: gcc.dg/tree-ssa/pr77445-2.c gcc.dg/tree-ssa/ssa-dce-3.c gcc.dg/tree-ssa/ssa-dom-thread-7.c I looked at these briefly and it seems like the problem here is that the output of the C front end after gimplification is different than it used to be, since I swapped in the C++ genericization code (it lowers to a LOOP_EXPR instead of directly to goto form, then the LOOP_EXPR gets lowered during gimplification). TBH, I don't really understand what optimizations these test cases are trying to test, and whether the pattern-matching is too fragile, whether the form of the code isn't something that actually tests the optimization, or whether the optimization is just not working on this input. So I'm not sure what to do about those failures! :-( I could change the genericizer to emit the same goto form that the C front end formerly emitted instead of the C++-style output, but that might just be papering over bugs elsewhere. Any advice on how to proceed here is welcome. If the patches are OK otherwise, maybe just file bugzilla issues for these regressions? -Sandra Sandra Loosemore (2): Move loop and switch tree data structures from cp/ to c-family/. Change C front end to emit structured loop and switch tree nodes. gcc/c-family/c-common.c | 24 +++ gcc/c-family/c-common.def | 24 +++ gcc/c-family/c-common.h | 53 ++++- gcc/c-family/c-dump.c | 38 ++++ gcc/c-family/c-gimplify.c | 414 ++++++++++++++++++++++++++++++++++++ gcc/c-family/c-pretty-print.c | 92 +++++++- gcc/c/c-decl.c | 18 +- gcc/c/c-lang.h | 3 +- gcc/c/c-objc-common.h | 2 + gcc/c/c-parser.c | 125 ++++++----- gcc/c/c-tree.h | 21 +- gcc/c/c-typeck.c | 227 ++++++-------------- gcc/cp/cp-gimplify.c | 347 ++---------------------------- gcc/cp/cp-objcp-common.c | 13 +- gcc/cp/cp-tree.def | 23 -- gcc/cp/cp-tree.h | 40 ---- gcc/cp/cxx-pretty-print.c | 78 ------- gcc/cp/dump.c | 31 --- gcc/doc/generic.texi | 56 +++-- gcc/objc/objc-act.c | 6 +- gcc/testsuite/gcc.dg/gomp/block-7.c | 12 +- 21 files changed, 859 insertions(+), 788 deletions(-) -- 2.8.1