Standard way to supply hints to branches (page 5)

September 06

Re: Standard way to supply hints to branches

Posted by Quirin Schroll
in reply to Richard (Rikki) Andrew Cattermole

Permalink

Quirin Schroll

Posted in reply to Richard (Rikki) Andrew Cattermole

Permalink

On Friday, 23 August 2024 at 17:43:33 UTC, Richard (Rikki) Andrew Cattermole wrote:

On 24/08/2024 5:39 AM, Manu wrote:

On Fri, 23 Aug 2024, 19:02 Iain Buclaw via Digitalmars-d, <digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com> wrote:

On Friday, 23 August 2024 at 02:23:37 UTC, Nicholas Wilson wrote:
 >
 > GDC probably has something similar too.

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect <https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect>

Regarding DMD, I recall it being said that its code generator
always treats the true branch as the "likely" code path taken. So
if you have `if (cond) cold; else hot;`, invert the condition for
the benefit of DMD.

Yes, I understand, and this is part of my point here; that leads to really ugly code and deep nested scopes. That's what I've been doing, and I don't want my program to look like that. It's just bad software.

For instance, an extraordinarily common function pattern is to receive some inputs, validate a few things, and then do the thing at the end with valid inputs.
Validations are usually a series of exclusionary checks framed as if(fails_validity_check) return;
That flow keeps code in a nice linear flow, it doesn't introduce any scopes at all... but it's the opposite of what the assume(true) prediction rule wants. This is what lead me to this; almost every if statement I write is predicted wrong... and I definitely don't want to solve that by writing functions with 10 level deep nested scopes.

If you want to propose something like an attribute on if statement, I'd be keen to see it (in ideas forum).

void func() {
	@unlikely
	if (random() > 0.5)
		return;
	@likely
	else {

	}
}

It should be a pragma. In general, a pragma is something a conforming compiler can ignore without changing semantics. Inline is a pragma for exactly this reason. An attribute makes no sense.

if (cond()) { pragma(unlikely); return; }

On 9/6/2024 3:53 AM, Quirin Schroll wrote: > Heuristics in the optimizer: Good. > Pandering to the heuristics of a specific compiler: Bad. All the compilers I know, by default, lay out the instructions in the same order the expressions are laid out in the source code.

On 9/6/2024 3:21 AM, Quirin Schroll wrote: > Early returns for unlikely-but-valid input like null pointers makes sense to me. I often write code so that the happy path is the first if. Andrei objected to this style :-/ > Other than that, there’s `if (...) throw ...;`, but basically all optimizers recognize this as an unlikely path. Sure, but that's only one case. Manu's functions are all nothrow. > This is your style, and IMO it’s a bad style. 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.)

``` int fun(int x) { int y; if (x < 0) goto Lreturn0; y = x * x; return y; Lreturn0: return 0; } ``` or: ``` int fun(int x) { if (x < 0) goto Lreturn0; { int y = x * x; return y; } Lreturn0: return 0; } ```

On Friday, 23 August 2024 at 01:47:37 UTC, Manu wrote: > I'm working on microcontrollers, and many don't have a branch predictor. They do "static" prediction, that is, they just predict branch-not-taken and it's on you to write your code as such, and that's not always possible. (like the loop condition in a for loop) > > This leads to a lot of awkward looking if's written in unnatural 'backwards' terms, and also, leads to undesirable depth of nested scopes. > > The compiler backend can and should re-jig the comparisons, but it needs to receive a hint which way is 'likely' from the programmer. > > How can we add an attribute to the branch condition that the backend can take advantage of? I think it needs to be in the language spec... unlikely_if(...) ...; else ...; :)

Forums