On Wednesday 13 April 2005 22:52, Pat Haugen wrote:
> Back to the original problem with the algorithm using edge frequency vs.
> block frequency. Would you agree that the correct thing to do is fix the
> code so that it uses block frequency, especially since the patch of
> Zdenek's you referenced
Steven Bosscher <[EMAIL PROTECTED]> wrote on 04/13/2005 02:10:07 PM:
>
> The problem with your original proposal is that computing
> post-dominance information really is expensive. Depending
> on how often this 50/50 case happens, in a real profile, it
> may or may not be worth the cost do as
On Wednesday 13 April 2005 20:46, Pat Haugen wrote:
> Steven Bosscher <[EMAIL PROTECTED]> wrote on 04/13/2005 09:39:55 AM:
> > On Wednesday 13 April 2005 00:18, Pat Haugen wrote:
> > > When we have a test block gating whether a loop should be
> > > entered, the new block frequency check causes the
Steven Bosscher <[EMAIL PROTECTED]> wrote on 04/13/2005 09:39:55 AM:
> On Wednesday 13 April 2005 00:18, Pat Haugen wrote:
> > When we have a test block gating whether a loop should be
> > entered, the new block frequency check causes the code to pick the
non-loop
> > path as the next block to
On Wednesday 13 April 2005 00:18, Pat Haugen wrote:
> When we have a test block gating whether a loop should be
> entered, the new block frequency check causes the code to pick the non-loop
> path as the next block to add to the trace since the loop header block has
> a higher frequency, and hence
I stumbled across the following and was interested in others thoughts
before I proceed any further.
The algorithm described in the comments of bb-reorder.c (and the paper
cited) talk about two parameters for controlling which blocks will be added
to traces. "Branch threshhold" refers to the b
