[LLVMdev] bug in the JIT global variable emitter

[Evan Cheng]

Thanks Nuno and Dale. Some comments:

+ /// allocateSpace - reserves space in the current block if any, or
+ /// allocate a new one of the given size + virtual void  
*allocateSpace(intptr_t Size, unsigned Alignment); +
Please capitalize "reserves".
+ /// allocateSpace - general-purpose space allocator
Better comments please. :-) Also please end the sentence with a period  
or Chris' head will explode. :-)
unsigned char *result = (unsigned char *)CurBlock+1;
  +
  + if (Alignment == 0) Alignment = 1;
+ result = (unsigned char*)(((intptr_t)result+Alignment-1) &
+ ~(intptr_t)(Alignment-1));
If type of result is intptr_t, you can avoid some of the casting, right?
Thanks!
Evan
On Oct 16, 2008, at 8:45 AM, Nuno Lopes wrote:

>>> Ok, thanks for the explanation. So my first patch doesn't work.
>>> Also, to be
>>> clear, this bug has nothing to do with overflowing the JIT memory
>>> buffer.
>>> I made another one that takes keeps the allocation of global
>>> variables in
>>> the JIT buffer, but it creates a new mem block if it doesn't exist
>>> (i.e.
>>> when dumping a global variable out of the scope of a function
>>> compilation).
>>> The patch is at:
>>> http://web.ist.utl.pt/nuno.lopes/llvm_jit_global_emitter2.txt
>>
>> OK, I think I finally understand this:  the allocation in
>> JIT::getOrEmitGlobalVariable doesn't call into JITEmitter but uses  
>> the
>> MachineCodeEmitter directly.  Thus, if you call it from outside the
>> JITEmitter, it won't update the data structures the JITEmitter relies
>> on.   In the usual case, the JITEmitter calls into JIT and updates  
>> its
>> own data structures, so that case works fine.
>
> exactly! :)  Thank you for summarizing. I hope others can now follow  
> this
> description.
>
>
>> I think adding a smarter allocateSpace to JITEmitter is the right
>> general idea, and your patch looks OK.   I'd like to get another pair
>> of eyes on it though, as I find this area not straightfoward:)   
>> Please
>> run the testsuite before committing.
>
> Yes, I would also appreciate more reviewers. The JIT's code is  
> particularly
> complex and I'm also quite new to the LLVM code..
>
> Thanks,
> Nuno
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081016/c4d46e8f/attachment.html>