[LLVMdev] tbaa.struct metadata and variable sized structs
hfinkel at anl.gov
Sun Sep 23 10:37:18 PDT 2012
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).
Couldn't you just make the last triple in the tbaa.struct metadata have
the maximum possible size ((uint64_t) -1)?
> 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
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev