llvm dev - Jul 2017 - Building aggregate types with dynamically sized elements

Hi,

I'm looking into ways to represent complex aggregate types whose members
and/or sub-members may be dynamically sized. This would conceptually
correspond to a C struct containing other structs and arrays, and some of
those arrays would have a length that is not known in compile time.

LLVM IR allows me to do this for a top-level array (using 0 as its LLVM
data type length and manually computing its needed allocation size).

As far as I understand, if I want to represent structs containing dynamic
arrays containing structs and so on, I will have to roll my own data size
computation, element pointer computation and so on. This however seems to
be a significant risk to portability and alignment handling.

Does anyone here have any experience with similar use cases, or any advice
on how to handle this?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/e2415bb2/attachment.html>

On 14 Jul 2017, at 09:12, Christer Swahn via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I'm looking into ways to represent complex aggregate types whose
members and/or sub-members may be dynamically sized. This would conceptually
correspond to a C struct containing other structs and arrays, and some of those
arrays would have a length that is not known in compile time.
Note: C does not support this.  GCC has an extension (variable length arrays in
structs), but clang doesn’t support it and it’s a terrible idea.
> LLVM IR allows me to do this for a top-level array (using 0 as its LLVM
data type length and manually computing its needed allocation size).
> 
> As far as I understand, if I want to represent structs containing dynamic
arrays containing structs and so on, I will have to roll my own data size
computation, element pointer computation and so on. This however seems to be a
significant risk to portability and alignment handling.
> 
> Does anyone here have any experience with similar use cases, or any advice
on how to handle this?
You will have to do this manually, via pointer casts of the results of GEPs.

David

>
> Note: C does not support this.  GCC has an extension (variable length
> arrays in structs), but clang doesn’t support it and it’s a terrible idea.
It might be complex but it is not terrible. Depends on the language
capabilities implementing it. Delphi for example allows exactly that and
finalizes its records through RTTI which allows to automatically free up
the memory.

2017-07-14 10:26 GMT+02:00 David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org>:
> On 14 Jul 2017, at 09:12, Christer Swahn via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > I'm looking into ways to represent complex aggregate types whose
members
> and/or sub-members may be dynamically sized. This would conceptually
> correspond to a C struct containing other structs and arrays, and some of
> those arrays would have a length that is not known in compile time.
>
> Note: C does not support this.  GCC has an extension (variable length
> arrays in structs), but clang doesn’t support it and it’s a terrible idea.
>
> > LLVM IR allows me to do this for a top-level array (using 0 as its
LLVM
> data type length and manually computing its needed allocation size).
> >
> > As far as I understand, if I want to represent structs containing
> dynamic arrays containing structs and so on, I will have to roll my own
> data size computation, element pointer computation and so on. This however
> seems to be a significant risk to portability and alignment handling.
> >
> > Does anyone here have any experience with similar use cases, or any
> advice on how to handle this?
>
> You will have to do this manually, via pointer casts of the results of
> GEPs.
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/73ad6f16/attachment.html>