digitalmars.D - [BetterC] Struct of size_ts and pointer decomposition before calling.
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: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.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.
May 05 2017