Slow compilation time for static arrays in structs

[samo76]

Hi. Suppose I have some C code that looks like this:

struct s3 {
   float x[2][8][144];
   s2 s[8][2];
};

struct s2 {
   float x[16][4];
   s3 s[8][2];
};

struct s1 {
   int x;
   s2 s[1];
};

Using Clang.jl, the following Julia code is generated:

struct s3
    x::NTuple{2, NTuple{8, NTuple{144, Cfloat}}}
    s::NTuple{8, NTuple{2, Cint}}
end

struct s2
    x::NTuple{16, NTuple{4, Cfloat}}
    s::NTuple{8, NTuple{2, s3}}
end

struct s1
    x::Cint
    s::NTuple{1, s2}
end

The 2 and 3 dimensional static arrays in the structs will generate long nested tuples that take forever to compile. This compilation latency is a well know issue in Julia. Is there a workaround in Clang.jl?

One of the workarounds I thought of is to create aliases for those structs and replace the static arrays with pointers. Then, in Julia, I would declare Julia arrays and fill them. Finally, in the C code, I would copy the data from the alias stucts to the originals structs. The alias stucts might look like this:

struct s3_a {
   float *x;
   s2_a *s;
};

struct s2_a {
   float *x;
   s3_a *s;
};

struct s1_a {
   int x;
   s2_a *s;
};

and will generate the following:

struct s3
    x::Ptr{Cfloat}
    s::Ptr{Cint}
end

struct s2
    x::Ptr{Cfloat}
    s::Ptr{s3}
end

struct s1
    x::Cint
    s::Ptr{s2}
end

Any help would be appreciated. Thanks in advance!

[Gnimuc]

I can't make it compile:

julia> ctx = create_context("test.h", args)
[ Info: Parsing headers...
test.h:3:4: error: unknown type name 's2'
test.h:8:4: error: must use 'struct' tag to refer to type 's3'
test.h:13:4: error: must use 'struct' tag to refer to type 's2'
Context(...)

[samo76]

I edited the original post to make it more comprehensive.

[Gnimuc]

https://godbolt.org/z/7fK7dr3PT

Your C code does not compile.

[Gnimuc]

I know what you tried to say. Please see my answers below. :)

[Gnimuc]

Using Clang.jl, the 2 and 3 dimensional static arrays in the structs will generate long nested tuples that take forever to compile. This compilation latency is a well know issue in Julia. Is there a workaround in Clang.jl?

You could write a rewriter function to manipulate the generated Julia expressions to anything you prefer.

Another way is to customize ctx.passes by manually changing the ctx.dag.nodes[your_struct_id_idx].type to Clang.Generators.nested_anonymous_type() before the Codegen pass.

[samo76]

The rewriter function is an option but rewrite the expressions to what? I can try, for example, replacing x::NTuple{2, NTuple{8, NTuple{144, Cfloat}}} with x::NTuple{2 * 8 * 144, Cfloat}. While I am still handling a (relatively) long tuple, this change might make the job of the Julia compiler easier? I am not an expert on the internals of Julia so I am not sure. I will need to try it myself and check.

FYI, I realize that this is more of a Julia problem than a Clang.jl package problem. :)

[Gnimuc]

replacing x::NTuple{2, NTuple{8, NTuple{144, Cfloat}}} with x::NTuple{2 * 8 * 144, Cfloat}

Exactly. The reason why we do it this way is that we need to map the alignment&layout of the struct on the Julia side to be the same as the one on the C side.

[Gnimuc]

Julia should handle x::NTuple{N,T} well.

[Gnimuc]

One of the workarounds I thought of is to create aliases for those structs and replace the static arrays with pointers. Then, in Julia, I would declare Julia arrays and fill them.

If you're maintaining the C code on your own, a good practice is to expose opaque types(e.g. typedef struct s3* s3_handle) with a set of API functions working with these opaque types(e.g. int create_s3(s3_handle x)).

[Gnimuc]

The definition of

struct s3 {
   float x[2][8][144];
   s2 s[8][2];
};

can go into the C source file. In this way, you can freely change the definition of s3 without updating the header file, so your C API is more stable.

[Gnimuc]

Another disadvantage of directly exposing the implementation detail of s3 is that when passing objects between Julia and C, s3 will be passed-by-value, so the memory footprint is not good whereas the opaque handle s3_handle just needs to copy a pointer and pass it through registers.

[samo76]

expose opaque types(e.g. typedef struct s3* s3_handle) with a set of API functions working with these opaque types(e.g. int create_s3(s3_handle x))

I like this solution. But it will come at a cost of doing some manual memory management that I was trying to avoid. 😄

Thank you very much @Gnimuc! I will refactor the code and get back to you with the results in a few days.