Re: Don't dump low gimple functions in gimple dump

[Tom de Vries <Tom_deVries at mentor dot com>]

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