Thread overview
[BetterC] Struct of size_ts and pointer decomposition before calling.
May 05, 2017
9il
May 05, 2017
jmh530
May 05, 2017
9il
May 05, 2017
Hi,

Could we introduce special attribute for struct definitions to make function ABI look like it accepts all fields as separate data (recursively)?

Its application should be constrained because alignment and etc.

Reasons:

1. clean unified _and_ hight level ABI with existing C libraries in both export from D and import to D directions.

2. Speed. For example LAPACK routine for small size matrixes would be 5-10% slower if we implement them using ndslices API.

3. Code size. Many LAPACK routines only call a lot of BLAS functions and do not compute anything itself. If we use ndslices for GLAS ABI, then code size will grow.

Note that BLAS/GLAS routines are not and should not be inlined.

2 and 3 are not jokes, please see code examples below.

Thanks,
Ilya

ldc2 -betterC -output-s -O -release -boundscheck=off testcc.d
-----
pragma(inline, false)
ref back(size_t length, sizediff_t stride, double* ptr)
{
	return ptr[(length - 1) * stride];
}

auto foo(size_t length, sizediff_t stride, double* ptr)
{
	return back(length, stride, ptr);
}

///////////

struct Slice
{
	size_t length;
	sizediff_t stride;
	double* ptr;
}

pragma(inline, false)
ref back(Slice slice)
{
	with(slice)
	return ptr[(length - 1) * stride];
}


auto foo(Slice slice)
{
	return back(slice);
}

-----



-----
    // back 1 (desired)
	decq	%rdx
	imulq	%rsi, %rdx
	leaq	(%rdi,%rdx,8), %rax
	retq

    // foo 1 (desired)
	pushq	%rax
Lcfi0:
	callq	__D6testcc4backFNaNbNcNimlPdZd
	movsd	(%rax), %xmm0
	popq	%rax
	retq

///////////

      // back 1 (current)
	movq	8(%rsp), %rax
	decq	%rax
	imulq	16(%rsp), %rax
	shlq	$3, %rax
	addq	24(%rsp), %rax
	retq

      // foo 1 (current)
	subq	$24, %rsp
Lcfi1:
	movq	48(%rsp), %rax
	movq	%rax, 16(%rsp)
	movq	32(%rsp), %rax
	movq	40(%rsp), %rcx
	movq	%rcx, 8(%rsp)
	movq	%rax, (%rsp)
	callq	__D6testcc4backFNaNbNcNiS6testcc5SliceZd
	movsd	(%rax), %xmm0
	addq	$24, %rsp
	retq
-----

May 05, 2017
On Friday, 5 May 2017 at 11:30:25 UTC, 9il wrote:
> Hi,
>
> Could we introduce special attribute for struct definitions to make function ABI look like it accepts all fields as separate data (recursively)?
>

I would think that a special attribute would require a DIP.

Would it be possible to fix this without an attribute? Such as with __traits(allMembers, Slice) and RepresentationTypeTuple!Slice? Or better compiler optimizations?
May 05, 2017
On Friday, 5 May 2017 at 15:05:21 UTC, jmh530 wrote:
> On Friday, 5 May 2017 at 11:30:25 UTC, 9il wrote:
>> Hi,
>>
>> Could we introduce special attribute for struct definitions to make function ABI look like it accepts all fields as separate data (recursively)?
>>
>
> I would think that a special attribute would require a DIP.

The attribute can be implemented as library definition + compiler magic.
Yes, probably DIP is required. But the idea is very simple and I want to get first feedback from compiler maintainers before we start to work on DIP.