<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>The advantages:</div><div><br class=""></div><div>1. A pointer to the struct offset can be converted to a pointer without any cost.</div><div>2. A nullpointer to a stretchy buffer can be treated as a zero length array. Consequently no actual struct allocation is needed to represent a zero length array.</div><div>3. A reference to the array is the same size as to a pointer.</div><div>4. It can be converted to and back from an pointer without losing any information about the size & capacity.</div><div><br class=""></div><div>The downsides are what we discuss. But it looks like I have to accept that I can only represent it as a pointer with unknown length in DWARF then?</div><div><br class=""></div><div>Best Regards,</div><div><br class=""></div><div>Christoffer</div><div><br class=""><blockquote type="cite" class=""><div class="">On 12 Nov 2019, at 21:49, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 12, 2019 at 12:44 PM Christoffer Lernö via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes, we’re actually viewing the struct at an offset.<br class="">
<br class="">
So basically it’s a struct like this:<br class="">
<br class="">
typedef struct {<br class="">
uint32_t size;<br class="">
uint32_t capacity;<br class="">
int array[0];<br class="">
} Foo;<br class="">
<br class="">
The whole thing is malloc:ed with extra bytes at the end, and capacity is set to that same number of extra bytes.<br class="">
<br class="">
What’s then passed around is actually the int pointer at an offset: &(foo->array)<br class="">
<br class="">
Using the that pointer we can obviously in a simple way recover the pointer to the struct, but can it be done so that LLVM and DWARF can identify the pointer as a pointer to a struct member for a certain struct?<br class="">
<br class="">
std::vector is as far as I know wrapping a pointer or two.<br class="">
<br class="">
The advantage of a stretchy buffer is that its length is recoverable even if stored as a pointer.</blockquote><div class=""><br class="">What's the advantage compared to a pointer to the struct, rather than a pointer to the array? (a pointer to this first element of the array would still have to be tagged differently from a pointer to an arbitrary int (either a singular int or an int somewhere in the array) to indicate that you can backtrack to find the length - so it's not like you get to generalize all int pointers) - I wouldn't expect (but don't know that much) that the extra constant offset on array indexing would be particularly expensive/observable?<br class=""><br class="">But yeah, I think you'd probably have some trouble getting DWARF consumers to handle the idea that the parameter type to a function is more than the type itself, or that pointers to that type actually point into the middle of the object instead of the start.<br class=""><br class="">Not insurmountable, but seems a bit expensive/complicated to try to make that work - but don't know what your other constraints/data are.<br class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> It’s also incredibly thin, only taking up the same size as a pointer – as opposed to std::vector which is likely 2 pointers long.<br class="">
<br class="">
<br class="">
Best Regards,<br class="">
<br class="">
Christoffer<br class="">
<br class="">
> Date: Tue, 12 Nov 2019 11:34:42 -0800<br class="">
> From: David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>><br class="">
> <br class="">
> the pointer points to the first element, and you walk backwards from there<br class="">
> to find the header details about the bounds/etc?<br class="">
> <br class="">
> In any case - I'd look at something like C++'s std::vector, which is a<br class="">
> variable length array, and model your situation similarly. I doubt there's<br class="">
> anything in particular you'll want to/be able to teach the optimizations<br class="">
> about your situation (nothing especially special that they know about<br class="">
> std::vector-like things either, that I know of - they maybe can deduce<br class="">
> certain things about how the bounds relate, and they certainly can optimize<br class="">
> a lot of std::vector usage) & debug info would probably look like<br class="">
> std::vector, in that it'd be a custom type, etc. Though if my guess above<br class="">
> was right about using prefix data to describe the bounds - that might be<br class="">
> hard to model in DWARF & you might be better off not being "tricky" like<br class="">
> that & modelling this closer to something that you could have written in C<br class="">
> or C++ more naturally.<br class="">
> <br class="">
> On Tue, Nov 12, 2019 at 4:14 AM Christoffer Lernö via llvm-dev <<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
> <br class="">
>> I’m considering building in variable arrays by implementing them as a<br class="">
>> stretchy buffer, that is a single allocation with header + elements with<br class="">
>> the pointer passed around pointing to the first element. (Example:<br class="">
>> <a href="https://www.gamasutra.com/blogs/NiklasGray/20180109/312683/Minimalist_container_library_in_C_part_1.php" rel="noreferrer" target="_blank" class="">https://www.gamasutra.com/blogs/NiklasGray/20180109/312683/Minimalist_container_library_in_C_part_1.php</a><br class="">
>> )<br class="">
>> <br class="">
>> Is there a good way to represent this in LLVM? I mean both in terms of<br class="">
>> helping the optimizer passes understand how the layout works and to make<br class="">
>> sure the debug info looks ok.<br class="">
>> <br class="">
>> <br class="">
>> Best regards,<br class="">
>> Christoffer<br class="">
>> _______________________________________________<br class="">
>> LLVM Developers mailing list<br class="">
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
<br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div></div>
</div></blockquote></div><br class=""></body></html>