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?
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?LLVM is still an abstract IR. LLVM does not specify struct sizes, the alignment is a property of the target. In LLVM, you can do target-independent array and struct element accesses, which get code generated to correct numeric offsets by the backends which know their target. If you are writing an LLVM pass and you absolutely NEED to know the numeric size of a struct, you must use the TargetData object which is target-specific. If you want to get the numeric size of a struct without using the LLVM API, it will require you to eesentially reimplement TargetData yourself in your programming language of choice. However, it does not change the fact that LLVM is and continues to be an abstraction of target machines. What do you mean by "build-time-dependent frontends"? 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. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu
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 Tue, 21 Jun 2005, 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?No, not at all. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/