Standard way to supply hints to branches
Manu
turkeyman at gmail.com
Fri Aug 23 17:41:27 UTC 2024
On Sat, 24 Aug 2024, 03:39 Manu, <turkeyman at gmail.com> wrote:
> On Fri, 23 Aug 2024, 19:02 Iain Buclaw via Digitalmars-d, <
> digitalmars-d at 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! ;)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20240824/ed42d906/attachment.htm>
More information about the Digitalmars-d
mailing list