This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with dom


Hello,

> > I have run into following problem with dom. One of the places
> > where cfg_altered is set is wrong:
> It's not really wrong, it's set this way on purpose, specifically
> to avoid the compile-time explosion you're seeing.

This works by pure luck only, I think.  In fact, the only thing
that prevents dom from unrolling loops just now is

  if (need_ssa_update_p ())
    return false;

condition in tree_can_merge_blocks_p, that prevents block merging
and keeps cfg unchanged.  While I do not have a testcase for this,
I would not be suprised if dom could be persuaded to completely unroll
a loop as it is.

Nevertheless, could you please add at least a short comment explaining
that this obvious mistake is an intended one to tree-ssa-dom.c?

> > So I tried the obvious fix (the patch above).  This fixes the problem,
> > but also causes dom to completely unroll loops sometimes, for
> > example for
> > 
> > void bar(int);
> > 
> > void foo(void)
> > {
> >   int i;
> > 
> >   for (i = 0; i < 10000; i++)
> >     {
> >       if (i & 65536)
> >         abort ();
> >       bar(i);
> >     }
> > }
> > 
> > (two exit conditions are necessary; for some reason, this won't
> > happen if "if (i & 65536) abort ();" is removed).  This of course
> > is not desirable (and it is very, very slow).  Any idea how to fix
> > the first problem without introducing the second one?
> I think the way to do this is to somehow limit the iterations when
> one or more backedges there threaded.
> 
> This may also fall out of the work Steven has started.  His changes
> limit DOM's ability to thread jumps when blocks get large, which is
> precisely what happens when DOM unrolls this loop completely. We
> get a single very very large basic block.  You might poke around with
> his change a little.

No, it unfortunately cannot help.  The new blocks are placed before the
loop, and jump threading only occurs inside the loop, so the sizes of
copied blocks remain small.

I guess the only real fix is to remove jump threading from dom and make
a separate, non-iterative pass for it.  Which of course is quite a bit
of work.

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]