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...

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...

For LDC see, https://github.com/ldc-developers/ldc/blob/master/runtime/druntime/src/ldc/intrinsics.di#L619 and see also `llvm_assume` just beneath it.

GDC probably has something similar too.

On Friday, 23 August 2024 at 01:47:37 UTC, Manu wrote:
> 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...

I always arrange it so, that the if-path is the likely one, and the else path is the unlikely one. This also makes the code more readable, and it is always possible to do so.
The compiler should optimize accordingly. No further indication should be necessary.

On Fri, 23 Aug 2024, 12:26 Nicholas Wilson via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> 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...
>
> For LDC see,
>
> https://github.com/ldc-developers/ldc/blob/master/runtime/druntime/src/ldc/intrinsics.di#L619 and see also `llvm_assume` just beneath it.
>
> GDC probably has something similar too.
>

Yes exactly, this is my point, we need something in the spec. I think there might be an opportunity to express branch prediction hints in a more user-friendly way than assume statements... But a language assume() would also be very useful!

>

On Fri, 23 Aug 2024, 19:02 Iain Buclaw via Digitalmars-d, < 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
>
>
> 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.

>

On Sat, 24 Aug 2024, 03:39 Manu, <turkeyman@gmail.com> wrote:

> On Fri, 23 Aug 2024, 19:02 Iain Buclaw via Digitalmars-d, < 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
>>
>>
>> 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.
>

Sorry, I meant *expect(true)*, not assume! ;)

>

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).

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

	}
}
```

On Sat, Aug 24, 2024 at 05:43:33AM +1200, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> 
> On 24/08/2024 5:39 AM, Manu wrote:
[...]
> > 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.
[...]
> If you want to propose something like an attribute on if statement, I'd be keen to see it (in ideas forum).
> 
> ```d
> void func() {
> 	@unlikely
> 	if (random() > 0.5)
> 		return;
> 	@likely
> 	else {
> 
> 	}
> }
> ```

This would be very nice to have.  I have quite a lot of code with early return, because it keeps nesting down to a sane level. But there are two opposing cases: the first is Manu's case, you want to validate parameters and abort early if you find something amiss.

But the second case is, you exit early to avoid an expensive computation if an initial stab got the right answer / is good enough / or the answer is cached and you just return it instead of recomputing it.

The second case works well with the assume(true) prediction rule.  But the first case works poorly.  I'd say a standardized attribute would be very nice to have.


T

-- 
Doubt is a self-fulfilling prophecy.