Displaying 20 results from an estimated 7000 matches similar to: "[LLVMdev] A lenient construction mode?"
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
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
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 =
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
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 Jul 29
1
[LLVMdev] PointerType without body, post-construction set type?
With StructType you can create an empty structure and then call setBody
later. How can one do the same thing with a PointerType?
I'm translating a recursive structure which includes pointers to itself.
I end up creating multiple copies of logically equivalent pointer types.
--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally
2012 Nov 18
0
[LLVMdev] What is a FunctionType really?
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 use as such.
> Can a
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
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 Nov 09
0
[LLVMdev] Error "Cannot emit physreg copy instruction"
Hey edA-qa mort-ora-y,
On Sat, Nov 9, 2013 at 6:47 AM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote:
> I'm getting an error that I don't know how to fix. I've isolated the
> input as much as I easily can. I've attached the file that produces the
> problem. Just calling "llc err.ll -o err.s" generates the error.
>
> I'm going to try and isolate
2013 Apr 14
2
[LLVMdev] source - target code of a pass
I don't want to do just a visual compare, i would like to manipulate,
iterate, over the "old" version of the function.
On 14 April 2013 11:49, edA-qa mort-ora-y <eda-qa at disemia.com> wrote:
> 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
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 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
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 Apr 12
0
[LLVMdev] object file/linking is missing my exception handlers
I can confirm now that my personality handler is invoked (I call
setHasUWTable on the functions now, but I'm not sure if that was the
difference). In any case it appears the behaviour of the
tables/handling is slightly different between the JIT and GCC linked.
I'm trying to figure out what this is now.
On 11/04/13 06:06, edA-qa mort-ora-y wrote:
> I have some exception handling which
2013 Oct 18
0
[LLVMdev] post-link Dwarf information appears wrong, works in JIT
I added several more clauses to see the result. It looks like the
landing pad information is generated correctly: I get the correct number
of action records, each record has a reasonable index into the type
table (from 1 to 9). The encoded address increment in 4 however, which
is unexpected since they are size 8 (in the JIT they increment by 8).
Whatever is causing that may also be responsible for
2013 Nov 04
0
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
But the incoming value from the landing pad will always be null, won't it?
If so, just iterate through the predecessors and add the terminator as the
incoming value if it's an invoke instruction and add the null value it's
not.
Won't that work?
On Mon, Nov 4, 2013 at 2:22 AM, edA-qa mort-ora-y <eda-qa at disemia.com>wrote:
> On 03/11/13 12:16, Henrique Santos wrote:
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 Feb 14
0
[LLVMdev] multiple LLVMContext or just one?
Hi,
LLVMContext was designed to support multithreading by holding the
compilation context for each thread in a separate LLVMContext. If you're
building modules in parallel you definitely need one LLVMContext per thread.
If you're talking about compiling multiple modules sequentially with a
single context I believe that should work, though I don't know how well
tested it is. I think