[LLVMdev] Re: Re: variable sized structs in LLVM

[Reid Spencer]

On Wed, 2005-06-22 at 01:17 -0400, Ed Cogburn wrote:
> One of LLVM's powerful (IMHO) selling points was the
> concept of a *complete*, abstract IR language which any independent
> frontend could write to (sending llvm-as unoptimized, even ugly, but
> correct, IR assembly that gets converted to optimized native code), without
> being dependent on LLVM's own code, i.e. just write to the IR spec, and be
> able to do anything that any frontend linked to LLVM itself, like Reid's
> Stacker, could do.

You can still do that. You just can't make assumptions about sizes and
alignments in a platform-neutral way. FWIW, you couldn't do it in Java
either for much the same reason: the details differ from platform to
platform. 

If your language depends on knowing the sizes/alignment/offset of actual
machines then the language is not, itself, machine neutral. However,
there are various techniques youc an use to do what you want. I've
already suggested how you can make variable sized structures by using a
pointer for one of the structure members.

As for Stacker, it doesn't generate LLVM assembly. At least not
directly. Its compiler directly manipulates the C++ IR from which either
bytecode or assembly can be generated.

> I guess what I'm suggesting is that both the variable struct & data
> alignment problems should be at some point abstracted away within LLVM's IR
> language,

They are!

> with data alignment issues ideally completely invisible to the
> user of LLVM's IR, 

They are!

> and with variable structs handled perhaps like GCC & C99
> eventually did to support variable sized structs in C.  

LLVM is not GCC nor C99, its LLVM. The notion doesn't exist in LLVM but
there are alternatives, several already suggested, that you can use
instead. It is likely that "under the covers" GCC and C99 are using
similar techniques.

If you believe that variable sized structs are a feature that is missing
in LLVM, then that's another discussion. However, LLVM needs to remain
"low level" and it is unlikely such a feature would gain much traction
since a combination of existing features can accomplish the same thing.
However, I'll ask other LLVMers weigh in on that discussion. 

Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050621/3f09c774/attachment.sig>