<div dir="ltr"><div dir="ltr"><br></div><br><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">llvm-dev@lists.llvm.org</a>> wrote:<br></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>
<br>
So basically it’s a struct like this:<br>
<br>
typedef struct {<br>
  uint32_t size;<br>
  uint32_t capacity;<br>
  int array[0];<br>
} Foo;<br>
<br>
The whole thing is malloc:ed with extra bytes at the end, and capacity is set to that same number of extra bytes.<br>
<br>
What’s then passed around is actually the int pointer at an offset: &(foo->array)<br>
<br>
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>
<br>
std::vector is as far as I know wrapping a pointer or two.<br>
<br>
The advantage of a stretchy buffer is that its length is recoverable even if stored as a pointer.</blockquote><div><br>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><br>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><br>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> </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>
<br>
<br>
Best Regards,<br>
<br>
Christoffer<br>
<br>
> Date: Tue, 12 Nov 2019 11:34:42 -0800<br>
> From: David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <br>
> the pointer points to the first element, and you walk backwards from there<br>
> to find the header details about the bounds/etc?<br>
> <br>
> In any case - I'd look at something like C++'s std::vector, which is a<br>
> variable length array, and model your situation similarly. I doubt there's<br>
> anything in particular you'll want to/be able to teach the optimizations<br>
> about your situation (nothing especially special that they know about<br>
> std::vector-like things either, that I know of - they maybe can deduce<br>
> certain things about how the bounds relate, and they certainly can optimize<br>
> a lot of std::vector usage) & debug info would probably look like<br>
> std::vector, in that it'd be a custom type, etc. Though if my guess above<br>
> was right about using prefix data to describe the bounds - that might be<br>
> hard to model in DWARF & you might be better off not being "tricky" like<br>
> that & modelling this closer to something that you could have written in C<br>
> or C++ more naturally.<br>
> <br>
> On Tue, Nov 12, 2019 at 4:14 AM Christoffer Lernö via llvm-dev <<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
>> I’m considering building in variable arrays by implementing them as a<br>
>> stretchy buffer, that is a single allocation with header + elements with<br>
>> the pointer passed around pointing to the first element. (Example:<br>
>> <a href="https://www.gamasutra.com/blogs/NiklasGray/20180109/312683/Minimalist_container_library_in_C_part_1.php" rel="noreferrer" target="_blank">https://www.gamasutra.com/blogs/NiklasGray/20180109/312683/Minimalist_container_library_in_C_part_1.php</a><br>
>> )<br>
>> <br>
>> Is there a good way to represent this in LLVM? I mean both in terms of<br>
>> helping the optimizer passes understand how the layout works and to make<br>
>> sure the debug info looks ok.<br>
>> <br>
>> <br>
>> Best regards,<br>
>> Christoffer<br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>