search for: curblocks

> + /// 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". ok. > + /// allocateSpace - general-purpose space allocator > Better comments please. :-) Also please end the sentence with a period > or Chris'

On Oct 16, 2008, at 11:29 AM, Nuno Lopes wrote: >> + /// 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". > > ok. > > >> + /// allocateSpace - general-purpose space allocator >>

Hello, I'm currently writing a function pass for LLVM and face the following problem. I want to store the address of a BasicBlock (or the label, as LLVM refers to it) in a local variable (AllocaInst). Later on I intend to indirectly branch to this address by "dereferencing" the variable. Is this possible? I tried creating an instance of AllocaInst but I'm not quite sure which

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'

...rom the rpcsvc-proto package. It didn't change between the working and failing case, as far as I could tell. Working case: sys_get_nfs_quotas: getquota_rslt: status : '1' bsize : '1024' active : 'yes' bhardlimit : '5000' bsoftlimit : '4000' curblocks : '1024' fhardlimit : '8' fsoftlimit : '0' curfiles : '0' btimeleft : '1' ftimeleft : '3918673920' Failing case sys_get_nfs_quotas: getquota_rslt: status : '1' bsize : '1024' active : 'yes' bhardlimit : '...

>> 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

Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index:

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL:

Check out the generated code for: -- #include <stdio.h> int main(int argc, char **argv) { static void *array[] = { &&foo, &&bar }; goto *array[argc % 2]; foo: puts("foo"); return 0; bar: puts("bar"); return 0; } -- Also, take a look at the class BlockAddress in llvm/IR/Constants.h. I think those might help you out. H. On Fri, Nov 1,

Tom, I think it might be productive to fork this thread to discuss making the requirements for upstreaming a new LLVM target more explicit and open. I'd also like to gauge interest in an idea I've discussed privately with a few community members, namely the concept of having a semi-official "incubation" system whereby proposed backends could get a trial run before becoming part