Standard way to supply hints to branches

[Manu]

On Wed, 11 Sept 2024 at 06:56, Walter Bright via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 9/10/2024 1:48 PM, Manu wrote:
> > On Sat, 7 Sept 2024 at 21:16, Walter Bright via Digitalmars-d
> >     Since CPU branch prediction for forward branches assumes they are
> not taken, it
> >     seems your style is statistically less likely. (As I assume the CPU
> designers
> >     did collect statistics on this.)
> >
> >
> > The statistical majority that you allude to is overwhelmingly
> dominated by the
> > branch UP and the end of every loop cycle.
> > Statistically speaking, almost all branches encountered during program
> flow are
> > up-branches at the end of loop cycles, which infers the rule that an up
> branch
> > should be predicted true, and therefore given a
> > sign-bit-branch-preiction strategy, down-branch must therefore predict
> false. No
> > other statistical realities past the loop continuation branch are
> relevant.
>
> I think that is what I wrote.
>
> > I'd also suggest that, other than maybe the statistical probability of a
> loop
> > continuation being a good choice to predict in the true case, the
> strategy of
> > sign-bit based prediction is more a useful tool for a compiler than an
> inherent
> > architectural optimising feature. It gives the compiler agency that it
> might not
> > otherwise have, and in the cases where the compiler can't infer
> meaningful
> > predictions, we should be able to supply them...
>
> I did write that forward branches were considered not likely, and backward
> branches likely. We are in agreement on that.
>

Okay, I lost the signal somewhere... what I'm essentially saying though, is
that it doesn't matter what the rule is or how it came about; the point is,
it's a tool the architecture offers which is most useful at the language
level. Laying out code to match this particular rule is not something
that's appropriate, because some other arch with whatever other primitive
strategy might come along.

Obfuscating the contorting code is not the goal or a reasonable solution;
we just want a mechanism in the language to take advantage of this general
category of support in whatever architecture.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20240911/5ff27e18/attachment.htm>