This is the mail archive of the 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

On Sun, 2005-09-11 at 10:37 +0200, Zdenek Dvorak wrote:
> 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.

> 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.

I can make this specific case significantly faster (by having DOM
delete dead statements), but it's still not going to be fast enough to
deal with

for (i = 0; i < (1 << 30); i++)
    if (i & 65536)
      abort ();
    bar (i);


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