--- Comment #14 from zadeck at naturalbridge dot com 2007-04-03 16:47
---
Subject: Re: [4.3] inf loop/long compile time, time spent
in var-tracking.c
steven at gcc dot gnu dot org wrote:
> --- Comment #13 from steven at gcc dot gnu dot org 2007-04-03 16:40
> ---
> So this m
--- Comment #13 from steven at gcc dot gnu dot org 2007-04-03 16:40 ---
So this may be a non-monotonous dataflow problem...?
Do we have the dataflow equations of the var-tracking problem somewhere? It'd
be interesting to check them against the actual implementation.
--
http://gcc.
--- Comment #12 from paolo dot bonzini at lu dot unisi dot ch 2007-04-03
13:59 ---
Subject: Re: [4.3] inf loop/long compile time, time spent
in var-tracking.c
> With dataflow branch that was compiled with profiling the testcase finishes
> not too slow:
This suggest that it is a bug
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-04-03 13:56
---
With dataflow branch that was compiled with profiling the testcase finishes
not too slow:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds second
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-03 13:50
---
At least all the attr_list stuff is O(N) as it uses a linked list for
static attrs
attrs_list_member (attrs list, tree decl, HOST_WIDE_INT offset)
{
for (; list; list = list->next)
if (list->decl == decl &&
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-03 13:45 ---
If I ignore abnormal edges the computation finishes. Of course I have no idea
what happens in that case ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
--- Comment #8 from bonzini at gnu dot org 2007-04-03 13:38 ---
I wouldn't say so. If there is a bug and the df solver oscillates, that's the
reason for the infinite loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-04-03 13:36 ---
Ok, let's defer a solution to after the df merge. Certainly something to look
at.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from bonzini at gnu dot org 2007-04-03 13:33 ---
anyway, the code looks well written. the dataflow_set_* functions look
inefficient, though. maybe it's also possible to replace hash tables with
pointer maps (there is a 1:1 relationships between decl nodes and their
DECL_
--- Comment #5 from bonzini at gnu dot org 2007-04-03 13:31 ---
well, for sure it would be possible to use df and a good example of that too.
But I'm not *that* knowledgeable about the df-*.c implementation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-03 13:30 ---
The easiest thing is probably to ignore abnormal edges:
Index: var-tracking.c
===
*** var-tracking.c (revision 123450)
--- var-tracking.c (wo
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-03 13:24 ---
Well, vt_find_locations is quadratic in the number of edges and basic blocks
which
we have a _lot_ in this testcase. Now, with the dataflow rewrite there may be
an easier way to compute the df problem. Maybe Paolo
--- Comment #2 from tbm at cyrius dot com 2007-03-31 18:29 ---
Created an attachment (id=13310)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13310&action=view)
preprocessed source
I attached the wrong file before. This one is correct.
--
http://gcc.gnu.org/bugzilla/show_bug
13 matches
Mail list logo
