On 22/10/15 14:27, Jakub Jelinek wrote:
The state before the patch is:
1) the omp_fn children created during the pre-SSA ompexp pass are dumped
first in the *.ssa dump and in all the following ones (these are created
as low gimple, non-SSA)
Hi,
I do see those child fns before the ssa dump, in the fixup_cfg1 dump
(and with -fipa-tree-all, also in the visibility dump, just after the
ompexp dump).
[ Not that I disagree with dumping the child fn in ompexp dump. ]
2) the omp_cpyfn children created during the pre-SSA ompexp pass are dumped
first in the *.omplower dump and in all the following ones (these are
created as high gimple)
3) the omp_fn children created during the parloops/ompexpssa passes
are dumped first post-IPA (or during IPA?) and in all the following ones
(these are created as SSA gimple)
3) is fine
Not fine for me though.
As I wrote earlier (
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01316.html ):
...
The problems I'm trying to solve with this patch are the following:
- even if you're compiling a single function, part of the function
occurs twice (once in the original, once in the split-off
function), making formulating scan-tree-dumps more complicated for
parloops.
- the intuitive thing is to look in the parloops tree-dump and look at
the original function and the split-off function, and think that the
split-off function is the immediate result of the split-off that
happened in the pass, which is incorrect (since it jumps back in the
pass list and traverses other passes before arriving back at
parloops).
Adding something like a flag -fno-dump-new-function would solve the
first problem, but not the second.
We could also dump new functions in a different dump file
src.c.new.123t.pass, and this would solve both problems. But it will
cause the 'where did that function go' confusion, certainly initially.
...
Thanks,
- Tom
