On 16/06/15 13:18, Richard Biener wrote:
On Mon, Jun 15, 2015 at 12:38 AM, Tom de Vries <tom_devr...@mentor.com> wrote:
On 14/06/15 23:49, Bernhard Reutner-Fischer wrote:
On June 14, 2015 10:55:59 AM GMT+02:00, Tom de Vries
<tom_devr...@mentor.com> wrote:
On 13/03/15 11:36, Richard Biener wrote:
On Fri, Mar 13, 2015 at 11:32 AM, Tom de Vries
<tom_devr...@mentor.com> wrote:
Hi,
this patch moves a bunch of early-out tests from the parloops pass
to the
gate function.
The only effect is for functions that we don't consider at all for
parallelization in the parloops pass. We no longer dump those in the
parloops dump file.
Bootstrapped and reg-tested on x86_64.
OK for stage1 trunk?
Does it work with -fdump-passes?
Hi,
with -fdump-passes now fixed to work on a dummy function (r222129), I'm
resubmitting this patch, split up in two patches.
The first patch moves two trivial early-exit tests to the parloops
gate.
The second patch moves the number_of_loops test to the parloops gate,
and adds a dummy loops structure in the dummy function for
-fdump-passes.
Bootstrapped and reg-tested on x86_64.
Both patches OK for trunk?
diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c
index 02f44eb..a1659a3 100644
--- a/gcc/tree-parloops.c
+++ b/gcc/tree-parloops.c
@@ -2535,10 +2535,6 @@ parallelize_loops (void)
source_location loop_loc;
/* Do not parallelize loops in the functions created by
parallelization. */
- if (parallelized_function_p (cfun->decl))
- return false;
- if (cfun->has_nonlocal_label)
- return false;
gcc_obstack_init (&parloop_obstack);
reduction_info_table_type reduction_list (10);
Now stray comment?
Stopped reading here.
Fixed in updated patch.
Also:
- made sure cfun is not used in the gate function
- added missing update of function header comment for
init_loops_structure
- improved comment in pass_manager::dump_passes.
OK for trunk?
For -fdump-passes this doesn't make much sense but I suppose
you are after not getting the untouched functions dumped. Note
that generally this is undesired for debugging (in my opinion)
as diffs from the pass dump before parloops to parloops will
contain a lot of spurious changes (and if the preceeding pass
is changed similarly the function we run parloops on is maybe
not even dumped there!).
So I question the general idea of the change.
I suppose there are two competing principles:
1. ensure the state before the pass is in the previous dump
2. only dump if changed
Indeed in general we use the first principle, although it doesn't hold
for f.i. pass_tree_loop and a function without loops.
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.
Any other ideas?
Thanks,
- Tom
