Misha Brukman wrote:> On Tue, Jun 21, 2005 at 02:11:22PM -0400, Ed Cogburn wrote: >> Reid Spencer wrote: >> > Its certainly possible to generate .ll files but its probably about >> > the same amount of work to use the LLVM API and there are >> > significant speed and validity benefits to doing so. >> >> Does this mean that LLVM is moving away from the idea of a truly >> abstract IR language, to being a set of development libraries for use >> by build-time-dependent frontends? >[snip]> > What do you mean by "build-time-dependent frontends"?Sorry, I meant frontends that link to LLVM's libraries, as opposed to spitting out .ll files for consumption by LLVM's assembler.> Frontends can be completely separate from the LLVM infrastructure and do > not even need to be linked with any LLVM classes to create LLVM code from > source languages.Unless, apparently, you're trying to implement variable-sized objects in your language. :) 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. 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, with data alignment issues ideally completely invisible to the user of LLVM's IR, and with variable structs handled perhaps like GCC & C99 eventually did to support variable sized structs in C. See 'Zero-length arrays': http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html#Zero-Length
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>
Hi Reid, On Tue, Jun 21, 2005 at 11:15:22PM -0700, Reid Spencer wrote:> 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.The only alternative so far in our case seems to be this one (quoting from a previous e-mail):> 4. Implement variable sized fields as separately allocated arrays so > that your example becomes: > %struct.array = type { int, int, int* } > The third field is allocated according to the actual size needed. > This is a bit more code generation but should be fairly efficient.If the LLVM optimizers are clever enough to figure out that the arrays doesn't really have to be allocated separately, but can be inlined within the allocation of the parent structure, and moreover no pointer indirection is needed, then it is indeed all that we need. In this sense, the feature Carl asked for is quite low level; we are looking for an effect that can be acheived either by optimizers working on a higher-level description in which the optimization hint cannot be expressed, or by giving the hint explicitely -- which so far doesn't seem possible portably in an assembler source. Armin
On Wed, 22 Jun 2005, Ed Cogburn wrote:>> Frontends can be completely separate from the LLVM infrastructure and do >> not even need to be linked with any LLVM classes to create LLVM code from >> source languages. > > > Unless, apparently, you're trying to implement variable-sized objects in > your language. :)Heh, hopefully my previous emails help clear this up. Variable sized objects should not be a problem for llvm.> 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.Yup!> 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, with data alignment issues ideally completely invisible to the > user of LLVM's IR, and with variable structs handled perhaps like GCC & C99 > eventually did to support variable sized structs in C. See 'Zero-length > arrays': > > http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html#Zero-LengthYup, I agree. If my previous email didn't clear this up, please lemme know :) -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
On Tue, 21 Jun 2005, Reid Spencer wrote:> 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.Yup.> If your language depends on knowing the sizes/alignment/offset of actual > machines then the language is not, itself, machine neutral.This is true.> 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.This is one way to do it, but it is not the only way. This is also less efficient for obvious reasons. It's better to just use variable sized arrays.> 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 really don't see what this has to do with anything. You're confusing what the LLVM API's provide and what the LLVM language/IR provides. Nothing in stacker depends on the LLVM API's: it could be written as a perl script that outputs .ll files.>> 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.This is true, but obviously LLVM wants to support C99 and other things that GCC does! :)> The notion doesn't exist in LLVMThis is not true.> 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.Not true, but for a different reason. C/C++ are already not target-independent (e.g. you can write code that detects endianness, header files are system specific, etc). Because of this, the llvm-gcc front-end doesn't really even try to emit super portable llvm code. As such, when using C VLA's, they just get lowered to allocations of exactly the right number of bytes, without the LLVM portable 'sizeof' construct being used.> 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.Fortunately, nothing in LLVM has to be there explicitly to support the feature. It's one of those high-level things that can be expressed with the low-level things we already have. :) -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/