I currently have a fair amount of code that will only run under GDC because of reliance on GDC-specific library routines. I’d like to ask whether I can find or implement equivalents in LDC2 to the GDC routines
        __builtin_expect()
and
        __builtin_unreachable() ?

Could someone point me toward the documentation for this general kind of stuff in LDC ?

On Tuesday, 14 July 2020 at 23:37:13 UTC, Cecil Ward wrote:
> I currently have a fair amount of code that will only run under GDC because of reliance on GDC-specific library routines. I’d like to ask whether I can find or implement equivalents in LDC2 to the GDC routines
>         __builtin_expect()
> and
>         __builtin_unreachable() ?

As Ilya already posted in another thread of yours, __builtin_expect is ldc.intrinsics.llvm_expect. Many other gcc builtins are available in ldc.gccbuiltins_<arch>. I don't think we expose `unreachable` though.

On Wednesday, 15 July 2020 at 08:20:48 UTC, kinke wrote:
> On Tuesday, 14 July 2020 at 23:37:13 UTC, Cecil Ward wrote:
>> I currently have a fair amount of code that will only run under GDC because of reliance on GDC-specific library routines. I’d like to ask whether I can find or implement equivalents in LDC2 to the GDC routines
>>         __builtin_expect()
>> and
>>         __builtin_unreachable() ?
>
> As Ilya already posted in another thread of yours, __builtin_expect is ldc.intrinsics.llvm_expect. Many other gcc builtins are available in ldc.gccbuiltins_<arch>. I don't think we expose `unreachable` though.

Oh, shame. There’s no __builtin_unreachable in ldc? I wonder if I could work around this with LDC then.

I’m using unreachable to declare the truth of a condition in release build so that the compiler can generate better code. The trick I use with GCC is to mark the body of some if-statement as unreachable. Then the compiler can remove a load of later if-test conditions or  remove if/else statements’ basic blocks.

On Tuesday, 14 July 2020 at 23:37:13 UTC, Cecil Ward wrote:
> I currently have a fair amount of code that will only run under GDC because of reliance on GDC-specific library routines. I’d like to ask whether I can find or implement equivalents in LDC2 to the GDC routines
>         __builtin_expect()
> and
>         __builtin_unreachable() ?
>
> Could someone point me toward the documentation for this general kind of stuff in LDC ?

I have just noticed this earlier thread by the way, it seems that I’m not original. Well at least I was on the right lines as others have had the same idea:
      https://forum.dlang.org/thread/ecycecfohgcqkfapiplk@forum.dlang.org

On Wednesday, 15 July 2020 at 23:31:39 UTC, Cecil Ward wrote:
> Oh, shame. There’s no __builtin_unreachable in ldc? I wonder if I could work around this with LDC then.

With D / LDC, there's almost always a workaround. In this case, using inline LLVM IR (as 'unreachable' is an IR instruction for LLVM):

-----
bool foo() nothrow;

void unreachable()
{
    import ldc.llvmasm;
    // due to a current LDC bug, a dummy parameter is required
    __ir!(`unreachable`, void, int)(0);
}

int bar()
{
    int r = 123;
    if (foo())
    {
        r = 456;
        unreachable();
    }
    return r;
}
-----

With -O, bar() is optimized to a `return 123`.

On Thursday, 16 July 2020 at 00:06:49 UTC, kinke wrote:
> With -O, bar() is optimized to a `return 123`.

(After the foo() call due to potential side effects.)

On 16 Jul 2020, at 0:31, Cecil Ward via digitalmars-d-ldc wrote:
> Oh, shame. There’s no __builtin_unreachable in ldc? I wonder if I could work around this with LDC then.

As a general note, LLVM tends not to provide intrinsics with semantics that can also be cleanly modelled in the regular LLVM IR. Clang implements virtually all GCC intrinsics in the respective header files, but does so by providing equivalent implementations manually for many of them.

As pointed out in the other response, you can easily access the functionality from LDC through inline IR still. A project to write an automatic converter to provide full GCC compatibility by building on Clang's implementation might be interesting, though.

 — David

On Thursday, 16 July 2020 at 00:12:06 UTC, kinke wrote:
> On Thursday, 16 July 2020 at 00:06:49 UTC, kinke wrote:
>> With -O, bar() is optimized to a `return 123`.
>
> (After the foo() call due to potential side effects.)

This is just what I have been working on : an assume() routine which modifies the compiler’s behaviour so that later code generation is optimised further by the knowledge gained by declarations of truths in assume( cond ) statements. Now you’ve been kind enough to give me the missing piece for ldc, I can add LDC support in too next.

Thank you so very much for your generous help guys. I’m an experienced professional asm and C programmer but I’m just starting out with D, and due to my poor health my memory and concentration are shot.

On Thursday, 16 July 2020 at 19:57:11 UTC, Cecil Ward wrote:
> On Thursday, 16 July 2020 at 00:12:06 UTC, kinke wrote:
>> On Thursday, 16 July 2020 at 00:06:49 UTC, kinke wrote:
>>> With -O, bar() is optimized to a `return 123`.
>>
>> (After the foo() call due to potential side effects.)
>
> This is just what I have been working on : an assume() routine which modifies the compiler’s behaviour so that later code generation is optimised further by the knowledge gained by declarations of truths in assume( cond ) statements. Now you’ve been kind enough to give me the missing piece for ldc, I can add LDC support in too next.
>
> Thank you so very much for your generous help guys. I’m an experienced professional asm and C programmer but I’m just starting out with D, and due to my poor health my memory and concentration are shot.

Incomplete assume implementation, sans LDC support tba, at https://forum.kitz.co.uk/index.php/topic,21771.msg419416.html#msg419416