llvm dev - Sep 2012 - [LLVMdev] 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.

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

On Sep 23, 2012, at 8:20 AM, 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).
> 
> 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?

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