search for: disemia

...ust be wrong with the Function Type. Try to debug into > runFunction to see which if condition fails. > Just a guess, if this is on 64 bit system the first argument type may be > int64 but needs to be int32. > > Yaron > > > > 2013/11/8 edA-qa mort-ora-y <eda-qa at disemia.com <mailto:eda-qa at disemia.com>> > > That makes it more mysterious then since I am indeed only calling a main > function. Perhaps I have to invoke it a different way. Here's my call I > have now: > > auto main = linker->getModule()-&gt...

...IT. > > However, with the supported calling sequences, you can probably replace > the char** with a void* to a structure so that practically anything can > be passed to your function inside the structure. > > Yaron > > > > 2013/11/8 edA-qa mort-ora-y <eda-qa at disemia.com <mailto:eda-qa at disemia.com>> > > I'm trying to get MCJIT working but I get the following errors: > Full-featured argument passing not supported yet! > UNREACHABLE executed at MCJIT.cpp:322! > I'm sure the first one will be a pr...

Something must be wrong with the Function Type. Try to debug into runFunction to see which if condition fails. Just a guess, if this is on 64 bit system the first argument type may be int64 but needs to be int32. Yaron 2013/11/8 edA-qa mort-ora-y <eda-qa at disemia.com> > That makes it more mysterious then since I am indeed only calling a main > function. Perhaps I have to invoke it a different way. Here's my call I > have now: > > auto main = linker->getModule()->getFunction( "main" ); > > std::ve...

Does this help? http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt On 11 Nov 2012, at 10:52, edA-qa mort-ora-y <eda-qa at disemia.com<mailto:eda-qa at disemia.com>> wrote: Is there a way to get the size of a type in the IR assembly code? I know the size must be known since alloca and getelementptr both implicitly use it, but I don't see any way to get access to the size directly. I know my final compiler will h...

Is there a way to get the size of a type in the IR assembly code? I know the size must be known since alloca and getelementptr both implicitly use it, but I don't see any way to get access to the size directly. I know my final compiler will have to get the size itself, but I'm just doing some simple tests directly in assembly now and am hoping there is an easy way to get the size of a

...unning it on the fly, supported by JIT but not MCJIT. However, with the supported calling sequences, you can probably replace the char** with a void* to a structure so that practically anything can be passed to your function inside the structure. Yaron 2013/11/8 edA-qa mort-ora-y <eda-qa at disemia.com> > I'm trying to get MCJIT working but I get the following errors: > Full-featured argument passing not supported yet! > UNREACHABLE executed at MCJIT.cpp:322! > I'm sure the first one will be a problem, but the second one prevents me > from testing an...

I'm trying to get MCJIT working but I get the following errors: Full-featured argument passing not supported yet! UNREACHABLE executed at MCJIT.cpp:322! I'm sure the first one will be a problem, but the second one prevents me from testing anything. I don't know how to fix the problem. My code works when using the non-MC JIT, and I added to my EngineBuilder: .setUseMCJIT(true)

...half Of Sean Silva > Sent: Wednesday, June 19, 2013 11:45 AM > To: edA-qa mort-ora-y > Cc: <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] How to deal with potentially unlimited count/length symbol names? > > On Wed, Jun 19, 2013 at 1:04 AM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > > > The problem is that if I derive the name from what the type contains the > > length of that name is essential unbound. So how does one generate > > names?  I'm thinking of just using a long hash and hoping I don't get > > accidental collisions...

On Mon, Apr 11, 2011 at 11:37 PM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: >> There isn't great support for this in the LLVM JIT, but IIRC some >> clients have managed this by subclassing the JITMemoryManager to copy >> the code when the function has finished being emitted.  I don't know >> if it's possible to ensure that...

On Wed, Jun 19, 2013 at 1:04 AM, edA-qa mort-ora-y <eda-qa at disemia.com>wrote: > > The problem is that if I derive the name from what the type contains the > length of that name is essential unbound. So how does one generate > names? I'm thinking of just using a long hash and hoping I don't get > accidental collisions. Surely there must...

In my language I have anonymous types (essentially tuples), and I have generated functions (like constructors) which are unique for these types. If the same type occurs in multiple modules however it should end up with only one definition being linked. Thus I need a way to give them the same name. The problem is that if I derive the name from what the type contains the length of that name is

...Wednesday, June 19, 2013 11:45 AM > > To: edA-qa mort-ora-y > > Cc: <llvmdev at cs.uiuc.edu> > > Subject: Re: [LLVMdev] How to deal with potentially unlimited > count/length symbol names? > > > > On Wed, Jun 19, 2013 at 1:04 AM, edA-qa mort-ora-y <eda-qa at disemia.com> > wrote: > > > > > The problem is that if I derive the name from what the type contains > the > > > length of that name is essential unbound. So how does one generate > > > names? I'm thinking of just using a long hash and hoping I don't get &...

On 04/11/2011 06:24 PM, Reid Kleckner wrote: > That should work perfectly fine. The LLVM JIT has support for > declaring and calling out to native functions in the application > through libffi. How about support for a custom memory model? I know this sounds odd, but basically the variables need to map to a specific block of memory: the global heap. The enclosing program uses memcpy to

...11:45 AM >> > To: edA-qa mort-ora-y >> > Cc: <llvmdev at cs.uiuc.edu> >> > Subject: Re: [LLVMdev] How to deal with potentially unlimited >> count/length symbol names? >> > >> > On Wed, Jun 19, 2013 at 1:04 AM, edA-qa mort-ora-y <eda-qa at disemia.com> >> wrote: >> > >> > > The problem is that if I derive the name from what the type contains >> the >> > > length of that name is essential unbound. So how does one generate >> > > names? I'm thinking of just using a long hash and...

I'm working on exception handling and having some trouble with type information. My personality/types work fine when running in the JIT, but when I produce object files and link them it fails. In particular, from an action record and the LSDA I get a type table entry. The problem is this doesn't appear to be pointing to a valid location. If I derefence it a segfault occurs. Are there

I can't find a lot of information about using structures directly as parameters, returns, and in registers. Is this fully supported on all platforms? Does it always convert to creating a hidden parameter when too large? For example (assume very.large is too big to fit in the target machine registers): define %very.large @get_struct() { %m1 = insertvalue %very.large undef, i32 10, 0 ...

On Sun, Nov 18, 2012 at 6:40 AM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > This may sound weird, but what exactly is a FunctionType? That is, in > terms of memory, or underlying value, what does the FunctionType > actually represent. At first I though it might be a pointer, but it is > not -- since you have to wrap a PointerType around it to u...

On 18/11/12 18:37, David Blaikie wrote: > Types, function or otherwise, have no in-memory representation. They > merely describe how bits should be interpreted. This is what I'm asking about the FunctionType. If I have a Pointer to a FunctionType it is clear how the bits should be interpreted, but what does the FunctionType it self say about the bits, if anything? In terms of use, can

...k our tools usually create an LLVMContext for each Module to be compiled. The llvm-link tool links multiple modules that share an LLVMContext (see tools/llvm-link/llvm-link.cpp), so that use case has at least been tested. - Lang. On Wed, Jan 30, 2013 at 10:20 PM, edA-qa mort-ora-y <eda-qa at disemia.com>wrote: > When building multiple modules should I be using multiple LLVMContext's > or just one of them shared between the modules? > > I'm a little bit uncertain in regards to how the types work. The IR type > checking appears to check exact ptrs for equality so how w...

On 14/04/13 18:40, Giacomo Tagliabue wrote: > I want to compare a program before and after having run a FunctionPass. > The purpose is merely didactic. What I would like to do is, during the I do a dump of the Module (Module.print) before and after running it through a PassManager (you could also use the Function.print method I think). You can put just a single pass in the PassManager to