tbaa.struct metadata and variable sized structs

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).

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.

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

I think it's beyond the scope of what I'm supposed to be working on for this
feature. But you're surely welcome to propose patches for this yourself.

Dan