LDC-specific _d_array_slice_copy (betterC)

[deviator]

Hello. I try build this simple example:

import core.stdc.stdio;
import std.algorithm : min;

extern (C) void main()
{
    char[256] buf;
    buf[] = '\0';

    auto str = "hello world";
    auto ln = min(buf.length, str.length);
    buf[0..ln] = str[0..ln];
    printf("%s\n", buf.ptr);
}

ldc2 -betterC bettercarray2.d

And I get error:

bettercarray2.o: In function `main':
bettercarray2.d:(.text.main[main]+0xd0): undefined reference to `_d_array_slice_copy'
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1

On dmd 2.076.1 I have same problem, but it solves by -noboundscheck flag.
If I try -boundscheck=off on ldc2 I have no effect.

ldc2 version is 1.6.0-beta1 (prebuild for linux x86_64)

[kinke]

As the name of the function suggests, this isn't directly related to array bounds checks, but with buf[0..ln] = str[0..ln] being mapped to druntime function _d_array_slice_copy() (which probably also checks that both slices feature the same length). We'll have to check what DMD does in this case; it's most likely unrelated to -betterC.

[kinke]

See https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/arrayinit.d#L142. According to the comment, it's only used for enabled assertions (also checking that the slices don't overlap); so an additional -release makes it work: https://godbolt.org/g/joZVzt

[deviator]

We'll have to check what DMD does in this case; it's most likely unrelated to -betterC.

It related to -betterC if it try use runtime when code builds with -betterC flag. -betterC must don't use runtime and all calls must be replaced with inline code or something else (c-runtime equivalent for example). But it's behavior isn't related to ldc, it's must be implement in dmd frontend...

This issue about difference between behavior of ldc and dmd.

[kinke]

It related to -betterC if it try use runtime when code builds with -betterC flag.

This divergence between LDC and DMD has absolutely nothing to do with -betterC. It just happens to be noticed with -betterC.

But it's behavior isn't related to ldc, it's must be implement in dmd frontend...

Well, there's not a single -betterC specific special case in the front-end right now. I.e., Walter's semantics have to be reimplemented by each compiler.

-betterC is a mess right now and probably will be for some time, if it ever gets to a point of really being useful for more wide-spread real-world code. What's your motivation for getting rid of druntime? Just curious as I don't understand the motivation unless one is targeting bare metal and/or extremely resource-constrained systems.

[kinke]

[Inlineability seems not to be a real issue as _d_array_slice_copy is optimized by the SimplifyDRuntimeCalls pass, which is enabled starting with -O2.]

Enabling that pass generally for -betterC seems like a good idea, it should prevent a few other druntime dependencies as well.

[PetarKirov]

@kinke what's the interaction between SimplifyDRuntimeCalls pass and the new templated druntime builtins, like the forthcoming (for LDC 1.7) https://github.com/dlang/druntime/blob/master/src/core/internal/arrayop.d#L28 ?

IMO, SimplifyDRuntimeCalls should handle the non-inline-able non-templated built-ins. With the end goal that after every built-in becomes a template function (probably quite far off from now) there should be no need for this pass on the LDC side.

[kinke]

No interaction at all, as it handles no arrayops, see https://github.com/ldc-developers/ldc/blob/master/gen/passes/SimplifyDRuntimeCalls.cpp#L344-L369.

[deviator]

@kinke

What's your motivation for getting rid of druntime? Just curious as I don't understand the motivation unless one is targeting bare metal and/or extremely resource-constrained systems.

I work in company that develop devices for industrial mainly for uninterruptible power source (monitoring, measurement etc). Some devices we develop on RPI, some on other ARM-boards, some devices fully develop by my colleagues and based on STM32, MSP430 etc. Last one use C for firmware. I try use D on ARM-board devices (with linux on the board) but have this problem. This is main blocker for using D on future projects on ARM-boards (impossible to determine place there throwing exception will lead to this error). Now I try eliminate druntime to get more predictable behavior. If -betterC mode will be finalized and stable I can try it for firmware.

[kinke]

You do realize there is no exception support whatsoever with -betterC?

So if you don't need them, you won't run into the EH issue anyway.

[deviator]

You do realize there is no exception support whatsoever with -betterC?

Yes, I know.

So if you don't need them, you won't run into the EH issue anyway.

Druntime can throws. For minimize probability of throwing I must check all data before any druntime call. And as a result, in any case I must put all druntime call in try-catch block. Or rewrite interested functions by myself as nothrow. In the end than it differs from -betterC by labor costs? With druntime I have probability of fatal error (I can't it catch), I have necessity to write many verification code (as without druntime), and in some cases need rewrite functions (as without druntime). If EH will works good I will not think about eliminate druntime.

[kinke]

Well, avoiding druntime is what needs to be done for -betterC anyway. The only thing which works out of the box so far are asserts as they map to the C assert in betterC mode. So -betterC doesn't magically solve your problem.

If you're so worried about hitting the EH issue, why don't you try disabling inlining as Joakim suggested in your issue? Or is your code performance-critical as well and that's really not an option?

[joakim-noah]

Even if performance might be an issue, he should still try disabling inlining to see if that's causing the problem.