I've been looking a bit at how haifa_sched.c sorts the ready list and think
there may be some room for added flexibility and/or improvement. I'll
throw out a few ideas for discussion.
Currently, within the ready_sort macro in haifa-sched.c, the call to qsort
is passed "rank_for_schedule" to help
I'm using store_data_bypass_p from recog.c as the guard for a define_bypass
within a machine description. I'm seeing the following warning/error that
I'd like to clean up.
cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:53265: warning:
Added a better subject line.. Pete.
[EMAIL PROTECTED] wrote on 09/30/2005 11:03:59 AM:
>
> I'm not entirely sure how gcc's CFG structure all fits together yet, so
> I'll ask for some input on this one:
>
> While looking through some dumps from a compile using -fprofile-use, I
> noticed the follo
I'm not entirely sure how gcc's CFG structure all fits together yet, so
I'll ask for some input on this one:
While looking through some dumps from a compile using -fprofile-use, I
noticed the following in the "jump" dump file:
Basic block 164 prev 163, next -2, loop_depth 0, count 1672, freq 148
Quick question on syntax in md files as I'm not finding the documentation
to explain it. If I see the following on an instruction definition:
(set_attr "type" "*")
What does * represent in this context as the value to assign to "type"?
Thanks.
Pete
>you may try adding -fmove-loop-invariants flag, which enables new
>invariant motion pass.
That cleaned up both my simplified test case, and the code it
originated from. It also cleaned up a few other cases where I
was noticing worse performance with FDO enabled. Thanks!!
Perhaps this option sh
> Do you have specific testcase? It would be interesting to see if new
> optimizer can catch up at least on kill-loop branch.
Here is a simplified version of what I observed. In the non-FDO case,
the loop invariant load of the constant 32 is removed from the loop.
When FDO is enabled, the load r
>A more likely source of performance degradation is that loop unrolling
>is enabled when profiling, and loop unrolling is almost always a bad
>pessimization on 32 bits x86 targets.
To clarify, I was compiling with -funroll-loops and -fpeel-loops
enabled in both cases.
The FDO slowdown in my case
There was some discussion a few weeks ago about some apps running slower
with FDO enabled.
I've recently investigated a similar situation using mainline. In my case,
the fact that the loop_optimize pass is disabled during FDO was the cause
of the slowdown. It appears that was recently disabled
