similar to: [LLVMdev] How to deal with potentially unlimited count/length symbol names?

Displaying 20 results from an estimated 8000 matches similar to: "[LLVMdev] How to deal with potentially unlimited count/length symbol names?"

2013 Jun 19
2
[LLVMdev] How to deal with potentially unlimited count/length symbol names?
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf 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
2013 Jun 19
0
[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. Surely there must be a better way? > Just
2013 Jun 19
1
[LLVMdev] How to deal with potentially unlimited count/length symbol names?
On 19/06/13 19:23, Eli Friedman wrote: > I think you've covered all the possible implementations. > > In terms of just generating long names, LLVM and common platforms can > handle long names reasonably well because C++ often uses such names. > Also, the Itanium C++ ABI has a scheme to compress repeated uses of the > same type which might be of interest; see >
2013 Jun 19
0
[LLVMdev] How to deal with potentially unlimited count/length symbol names?
On Wed, Jun 19, 2013 at 3:39 PM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf 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
2013 Jun 20
1
[LLVMdev] How to deal with potentially unlimited count/length symbol names?
if youd don't care the readabilit, you can compress the function name.... 在 2013-6-20 上午7:22,"Sean Silva" <silvas at purdue.edu>写道: > > > > On Wed, Jun 19, 2013 at 3:39 PM, Robinson, Paul < > Paul_Robinson at playstation.sony.com> wrote: > >> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of
2013 Jun 19
0
[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: > 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
2013 Nov 08
2
[LLVMdev] UNREACHABLE executed at MCJIT.cpp:322!
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::vector<llvm::GenericValue> args(2); args[0].IntVal = llvm::APInt( platform::abi_int_size, 0 ); args[1].PointerVal = nullptr; llvm::GenericValue gv =
2013 Nov 08
1
[LLVMdev] UNREACHABLE executed at MCJIT.cpp:322!
It was the return type which was i64. I changed it also to my abi_int_size and it works now. I have to take care of a few other type translations, but it looks like MCJIT is working now. Thank you. On 08/11/13 18:12, Yaron Keren wrote: > 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
2012 Nov 11
4
[LLVMdev] IR sizeof?
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
2013 Nov 08
0
[LLVMdev] UNREACHABLE executed at MCJIT.cpp:322!
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
2012 Nov 11
0
[LLVMdev] IR sizeof?
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
2013 Nov 08
2
[LLVMdev] UNREACHABLE executed at MCJIT.cpp:322!
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)
2013 Nov 08
0
[LLVMdev] UNREACHABLE executed at MCJIT.cpp:322!
MCJIT::runFunction supports only main-style argument passing but not other cases like the JIT. These types of arguments will work: (int, char**, char**) (int, char**) (int) (void) The general case is not supported since it requires creating a small stub function, compiling and running it on the fly, supported by JIT but not MCJIT. However, with the supported calling sequences, you can probably
2013 Oct 17
4
[LLVMdev] post-link Dwarf information appears wrong, works in JIT
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
2013 Apr 25
4
[LLVMdev] trouble understanding value in dwarf exception mechanism
I'm having trouble understanding the value in the way exceptions are handled on Linux, the dwarf/system V ABI exception spec. The mechanism allows for both cleanup routines and catch handlers, where by cleanup handlers don't stop the search for a normal handler. The personality function (I guess no longer part of the standard, but a C++ thing) can also compare types of the landingpads.
2013 Apr 14
1
[LLVMdev] source - target code of a pass
On 14/04/13 19:50, edA-qa mort-ora-y wrote: > I don't know if there is an explicit clone method, but you could do the > printing and then parse it again. That would effectively create a clone > of the object. It appears the "llvm" namespace has several Clone functions. Thus you should be able to do what I suggested: Clone the function, run the original through the
2012 Nov 18
2
[LLVMdev] What is a FunctionType really?
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 use as such. Can a FunctionType value actually exist, or is strictly an abstract concept? In particular, can I actually directly define
2013 Apr 14
2
[LLVMdev] source - target code of a pass
Hello, 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 runOnFunction() method, "save" somehow the instruction set and cfg of the function, run the optimization. and then compare the two codes, before and after the transformation. Is there an automatic way tho do that, or a suggested approach?
2011 Apr 12
2
[LLVMdev] appropriate for run-time compilation of DSL?
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
2012 Nov 18
1
[LLVMdev] What is a FunctionType really?
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