User account creation filtered due to spam.
The following patch:
--- 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))
- if (freq < BB_FREQ_MAX / PARAM_VALUE (HOT_BB_FREQUENCY_FRACTION))
+ if (freq < ENTRY_BLOCK_PTR->frequency / PARAM_VALUE
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.
I suppose the same problem can be seen if you make the function artificially
hot by calling it from inside a loop.
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.
Loop distribution shouldn't fail if loop header copying was applied and it would
be nice to know why it does.
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.