On Sat, 24 Aug 2024 at 10:11, Nicholas Wilson via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Friday, 23 August 2024 at 20:08:53 UTC, kinke wrote:
> > I suggest adding a `core.builtins.expect()` intrinsic to standardize the existing LDC and GDC intrinsics, adding a dummy (`pragma(inline, true)`!) identity function for DMD. No need for introducing statement-level UDAs, other compiler magic, complicating language/spec etc. `core.attribute` already does this for magic UDAs.
>
> https://github.com/dlang/dmd/pull/16807


Thanks Nick! That's good to have.

That said, I still feel using expect() is pretty invasive.
If you have a bunch of existing code, marking it up is a fiddly
transformation, and hurts readability:

if (fails_validation)
  return -1;
if (check_for_lilely_case)
  return v;
return calculate(v);


// invasive and pretty severely damages readibility
if (expect(fails_validation, false))
  return -1;
if (expect(check_for_lilely_case, true))
  return v;
return calculate(v);


// paste token on end of line, doesn't really affect readibility at all
if (fails_validation) @unlikely
  return -1;
if (check_for_lilely_case) @likely
  return v;
return calculate(v);


An attribute attaching to control statements would definitely be nice for my money...

On Saturday, 24 August 2024 at 01:26:43 UTC, Manu wrote:
> Thanks Nick! That's good to have.
>
> That said, I still feel using expect() is pretty invasive.
> If you have a bunch of existing code, marking it up is a fiddly
> transformation, and hurts readability:
>
> if (fails_validation)
>   return -1;
> if (check_for_lilely_case)
>   return v;
> return calculate(v);
>
>
> // invasive and pretty severely damages readibility
> if (expect(fails_validation, false))
>   return -1;
> if (expect(check_for_lilely_case, true))
>   return v;
> return calculate(v);
>
>
> // paste token on end of line, doesn't really affect readibility at all
> if (fails_validation) @unlikely
>   return -1;
> if (check_for_lilely_case) @likely
>   return v;
> return calculate(v);
>
>
> An attribute attaching to control statements would definitely be nice for my money...

note there is nothing stopping you from doing

```d
pragma (inline, true) bool unlikely(bool val) => expect(val, false);
pragma (inline, true) bool   likely(bool val) => expect(val, true);

if (unlikely(fails_validation))
  return -1;
if (check_for_liklely_case.likely) // if you feel that (ab)using UFCS is prettier
  return v;
return calculate(v)
```

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)

Stupid questions: does PGO work on the microcontrollers, and  have you tried PGO?

On 8/23/2024 1:56 AM, Iain Buclaw wrote:
> 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.

That's correct.

I recently learned a syntactical trick on how to do this.

```
if (x) return;
if (y) return;
if (z) return;
hotPath();
```

Rewrite as:

```
do
{
    if (x) break;
    if (y) break;
    if (z) break;
    hotPath();
} while (0);
```

Of course, this will also work:

```
if (x) goto Lreturn;
if (y) goto Lreturn;
if (z) goto Lreturn;
hotPath();
Lreturn:
```

On 8/23/2024 7:24 PM, Walter Bright wrote:
> On 8/23/2024 1:56 AM, Iain Buclaw wrote:
>> 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.
> 
> That's correct.

It's not pedantically correct. More precisely, any code following the `if` is presumed to be the hot path. A branch instruction doesn't count, i.e. it's the branch-not-taken that is considered the hot path.

Walter Bright kirjoitti 24.8.2024 klo 6.37:
> It's not pedantically correct. More precisely, any code following the `if` is presumed to be the hot path. A branch instruction doesn't count, i.e. it's the branch-not-taken that is considered the hot path.
Can you elaborate? I'm not sure what's the difference between `if` and a branch instruction.

On 24/08/2024 5:48 PM, Dukc wrote:
> Walter Bright kirjoitti 24.8.2024 klo 6.37:
>> It's not pedantically correct. More precisely, any code following the `if` is presumed to be the hot path. A branch instruction doesn't count, i.e. it's the branch-not-taken that is considered the hot path.
> Can you elaborate? I'm not sure what's the difference between `if` and a branch instruction.

In pseudo assembly it would look something like this:

```
test condition;
jump-if-zero ColdPath;

HotPath:
	...
	goto End;

ColdPath:
	...

End:
	...
```


In pseudo code:

```
if (condition == 0)
	goto ColdPath;

HotPath:
{
}
goto End;

ColdPath:
{
}

End:
{
}
```

Converted to an if statement:

```d
if (condition) {
	// cold path
} else {
	// hot path
}

// hot path at end
``

In essence in the CPU, any instruction that jumps around conditionally can be assumed to not be taken. Note: this is very CPU dependent and in the last 15 years has gotten a LOT smarter.