Hi Reid, Reid Spencer wrote:> Yes, for that you need TargetData: > > http://illuvium.net/docs/doxygen/classllvm_1_1TargetData.htmlI feared that that would be the answer :-). We're not using the LLVM-API at the moment. We're just generating a .ll file 'by hand', e.g. via simple string operations. I guess we get what we deserve :-). Thanks for your help, Carl Friedrich
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. Here's some ideas on how to handle this situation for the variable sized structs you need for PyPy: 1. Don't support the feature in your first release (not sure if this is viable or not). 2. Make some worst case assumptions about size and alignment (8 bytes) and allocate that size, possibly over-allocating memory. 3. Figure out the exact maximum size of the struct so you can declare the type correctly. 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. Reid. On Tue, 2005-06-21 at 00:40 +0200, Carl Friedrich Bolz wrote:> Hi Reid, > > Reid Spencer wrote: > > Yes, for that you need TargetData: > > > > http://illuvium.net/docs/doxygen/classllvm_1_1TargetData.html > > I feared that that would be the answer :-). We're not using the LLVM-API > at the moment. We're just generating a .ll file 'by hand', e.g. via > simple string operations. I guess we get what we deserve :-). > > Thanks for your help, > > Carl Friedrich > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- 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/20050620/78ba6d6b/attachment.sig>
Hi Reid! 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.I can't really judge that because I've not used the API yet. For now creating .ll files seem like a good solution since string handling is so easy in Python. I guess we will have to use the API at a later point when we start to work on implementing jit compilation/dynamic specialization and want to directly use emitted functions.> > Here's some ideas on how to handle this situation for the variable sized > structs you need for PyPy: > > 1. Don't support the feature in your first release (not sure if this is > viable or not).A lot of things are implemented as var-sized struct, e.g. strings are a struct with a hash and the chars, so we can't just leave 'em out.> > 2. Make some worst case assumptions about size and alignment (8 bytes) > and allocate that size, possibly over-allocating memory.yes, this might a quick solution for the next weeks since we don't deallocate _any_ memory at the moment because the garbage collector is not implemented yet :-). The GC is what I'll be working on during the summer.> > 3. Figure out the exact maximum size of the struct so you can declare > the type correctly. > 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.I guess we will probably do that. Thanks for your suggestions, Carl Friedrich
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, 21 Jun 2005, Carl Friedrich Bolz wrote:> Reid Spencer wrote: >> Yes, for that you need TargetData: >> >> http://illuvium.net/docs/doxygen/classllvm_1_1TargetData.html > > I feared that that would be the answer :-). We're not using the LLVM-API at > the moment. We're just generating a .ll file 'by hand', e.g. via simple > string operations.This is just fine. The only advantage to using the llvm C++ API's are compile time speed and integration with the JIT. If neither of those is a priority yet, emitting text is a great way to go!> I guess we get what we deserve :-).Not at all, this is a great way to go. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/