The best way of generating a good representation for an array with header?

I’m considering building in variable arrays by implementing them as a stretchy buffer, that is a single allocation with header + elements with the pointer passed around pointing to the first element. (Example: Minimalist container library in C (part 1))

Is there a good way to represent this in LLVM? I mean both in terms of helping the optimizer passes understand how the layout works and to make sure the debug info looks ok.

Best regards,

the pointer points to the first element, and you walk backwards from there to find the header details about the bounds/etc?

In any case - I’d look at something like C++'s std::vector, which is a variable length array, and model your situation similarly. I doubt there’s anything in particular you’ll want to/be able to teach the optimizations about your situation (nothing especially special that they know about std::vector-like things either, that I know of - they maybe can deduce certain things about how the bounds relate, and they certainly can optimize a lot of std::vector usage) & debug info would probably look like std::vector, in that it’d be a custom type, etc. Though if my guess above was right about using prefix data to describe the bounds - that might be hard to model in DWARF & you might be better off not being “tricky” like that & modelling this closer to something that you could have written in C or C++ more naturally.

OpenVMS has something called a “varstring” (IIRC) which is a 16-bit length followed by the string data. I don’t know if John Reagan has support for any VMS languages with that construct yet, but I’d expect it to be effectively a struct with the length as the first member and a VLA-like thing holding the array. Your container might want to look something like that.


Sorry for the delay. I’ve been away from the computer. Yes, we have already coded up support for our Pascal’s VARYING OF CHAR (based on PL/Is VARYING OF CHAR) which has a 16-bit length at the front. The layout is also influenced by the VAX architecture’s MOVC/CMPC instructions which have a max size of 64K. We have vendor-specific DWARF tags for these VS strings. I’m not sure if any of this helps, but send email if you’d like to see any examples (our current cross-compiler environment is based on ancient 3.4.2 so you’ll have extrapolate to something newer - we’re working on a bootstrap now to 9.0.0)