[LLVMdev] tbaa.struct metadata and variable sized structs

[Hal Finkel]

On Sun, 23 Sep 2012 17:20:38 +0200
Duncan Sands <baldrick at free.fr> wrote:

> Hi Dan, I was thinking about having dragonegg produce tbaa.struct
> metadata and I realized that there is a problem with variable sized
> structs.  What I have in mind is for example a struct with a few
> ordinary fields and a variable length array at the end.  In Ada these
> can be copied; dragonegg turns such copies into calls to llvm.memcpy
> with a non-constant size parameter.  It would be nice to use
> tbaa.struct metadata with such structs, not to describe the variable
> sized part but to describe the tbaa properties and gaps in the fixed
> size normal part. Unfortunately with the current tbaa.struct setup
> anything that isn't specified as a field is considered to be a gap.
> Since there is no way to describe the variable sized part as a field,
> it will be considered to be a gap, which would be fatal.  (Note that
> the optimizers, eg inlining, may discover the actual size of the
> variable sized struct, resulting in an llvm.memcpy of fixed size with
> an apparent gap at the end, so such structs may not appear variable
> sized at the LLVM level).

Duncan,

Couldn't you just make the last triple in the tbaa.struct metadata have
the maximum possible size ((uint64_t) -1)?

 -Hal

> 
> A possible solution is to say that gaps should be made explicit in
> tbaa.struct metadata.  That way for a variable sized struct the
> ordinary fields and the gaps between them would be explicitly output
> in the metadata, and "the rest" would be treated conservatively as
> something that has to be copied with unknown aliasing properties.
> 
> What do you think?
> 
> Best wishes, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory