User account creation filtered due to spam.

Bug 47033 - loop distribution has problems on sane testcases
Summary: loop distribution has problems on sane testcases
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: missed-optimization
Depends on:
Reported: 2010-12-21 19:19 UTC by Jan Hubicka
Modified: 2011-01-01 13:38 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2010-12-29 16:12:57


Note You need to log in before you can comment on or make changes to this bug.
Description Jan Hubicka 2010-12-21 19:19:12 UTC
The following patch:
Index: predict.c
--- predict.c   (revision 168047)
+++ predict.c   (working copy)
@@ -126,7 +126,7 @@ maybe_hot_frequency_p (int freq)
   if (node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
       && freq <= (ENTRY_BLOCK_PTR->frequency * 2 / 3))
     return false;
+  if (freq < ENTRY_BLOCK_PTR->frequency / PARAM_VALUE
     return false;
   return true;
makes the testcase gcc.dg/tree-ssa/ldist-pr45948.c  to fail.

The testcase seems to test if the loop is converted to memsets. The problem is that with the patch above the code is considered hot and loop gets header copied as a result the code in loop distribution seems confused.
Profile info is wrong and one copy of loop stays in the code.
Comment 1 Richard Biener 2010-12-28 16:11:35 UTC
I suppose the same problem can be seen if you make the function artificially
hot by calling it from inside a loop.
Comment 2 Sebastian Pop 2010-12-29 05:15:19 UTC
Is the problem that the testcase is too fragile and we have to fix the pattern expected by the testcase?

I suppose we can just disable the scan for memset and leave the testcase test for no ICE while compiling it.
Comment 3 Richard Biener 2010-12-29 16:12:57 UTC
Loop distribution shouldn't fail if loop header copying was applied and it would
be nice to know why it does.
Comment 4 Jan Hubicka 2011-01-01 13:29:47 UTC
I at least checked in the fix for uninitialized var. It would indeed be nice to know why the generated code is worse than before.