This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Don't dump low gimple functions in gimple dump
- From: Tom de Vries <Tom_deVries at mentor dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Thomas Schwinge <thomas at codesourcery dot com>, Jan Hubicka <hubicka at ucw dot cz>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Julian Brown <julian at codesourcery dot com>
- Date: Thu, 22 Oct 2015 14:51:34 +0200
- Subject: Re: Don't dump low gimple functions in gimple dump
- Authentication-results: sourceware.org; auth=none
- References: <87k3bnecq3 dot fsf at schwinge dot name> <537B0F6D dot 7060808 at mentor dot com> <87617mndrv dot fsf at kepler dot schwinge dot homeip dot net> <CAFiYyc1i2GAj7JA2Ao1NSxT=oAy83uvVboYcvxGcUe69h-tsvA at mail dot gmail dot com> <55706892 dot 8050701 at mentor dot com> <20151022122717 dot GO478 at tucnak dot redhat 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