Hi,
I have hit problem with this pass several times. OMP is split into two passes,
one run before CFG construction (lower_omp) and other after (expand_omp).
Their purpose (as I understand it) is to outline part of the function body
into child function. This happens in two steps and part of body
(DECL_STRUCT_FUNCTION,
some declarations etc) are built during lowering, while rest of body is build
during expansion.
For this reason we need quite few hacks in symbol table to not take the
function body away (the child function appears not as declaration until
late) and also omp code contains some ugly hacks with flags.
According to dicussion with Jakub, I do not see reason why not move whole
thing upwards into lowering. This make the child functio nto get throug
optimization as a regular function and things works smoother.
Bootstrapped/regtested x86_64, seem to make sense?
Honza
* passes.c (init_optimization_passes): Move expand_omp into
late passes.
Index: passes.c
===================================================================
--- passes.c (revision 199343)
+++ passes.c (working copy)
@@ -1299,6 +1299,7 @@ init_optimization_passes (void)
NEXT_PASS (pass_refactor_eh);
NEXT_PASS (pass_lower_eh);
NEXT_PASS (pass_build_cfg);
+ NEXT_PASS (pass_expand_omp);
NEXT_PASS (pass_warn_function_return);
NEXT_PASS (pass_build_cgraph_edges);
*p = NULL;
@@ -1312,7 +1313,6 @@ init_optimization_passes (void)
struct opt_pass **p = &pass_early_local_passes.pass.sub;
NEXT_PASS (pass_fixup_cfg);
NEXT_PASS (pass_init_datastructures);
- NEXT_PASS (pass_expand_omp);
NEXT_PASS (pass_build_ssa);
NEXT_PASS (pass_early_warn_uninitialized);
