similar to: lli size

Hey there, Searching via the web is not producing answers.... So I thought I would ask the gods of llvm. :-) I'd like to experiment with the llc in conjunction with msil. but I am running into this error: llc-mp-2.9 test.ll -march=msil /opt/local/libexec/llvm-2.9/bin/llc: error: invalid target 'msil'. the version string is: llc-mp-2.9 --version Low Level Virtual Machine

Greetings, I am searching for an alternative to sun's java implementation - one that is not under gpl.. I've been reading the vmkit code for JNI.. And I notice that it is not completely filled out yet... That's fine though, I see there is filled in function like most of the non implemented functions.. Couple of questions: Is the entire llvm required for java/cli vmkit to run?

Dear All, I am using wilcox.test to test two samples, data_a and data_b, earch sample has 3 replicates, suppose data_a and data_b are 20*3 matrix. Then I used the following to test the null hypothesis (they are from same distribution.): wilcox.test(x=data_a, y=data_b, alternative="g") I got pvalue = 1.90806170863311e-09. When I switched data_a and data_b by doing the following:

Hi, I'm using metafor to perform a mixed-effects meta-analysis. I'd like to test whether the effect is different for animals and plants/whether "group" (animal/plant) influences the effect size, but am having trouble interpreting the results I get. I've read previous posts about QM in metafor, but I'm still a bit confused. I've dummy-coded the factors:

Hi Armin, Argument parsing isn't handled by the JIT. This sounds like you're making redundant calls to cl::ParseCommandLineOptions ? Deleting the ExecutionEngine and any RTDyldMemoryManager instances that you've created should be enough to reset the JIT. Cheers, Lang. On Tue, Jan 20, 2015 at 12:38 PM, Armin Steinhoff <armin at steinhoff.de> wrote: > > Hi, > >

Over one year passed now, did anybody made any progress regarding this issue? On 9 February 2017 at 16:33, Gaetano Checinski <gaetano.checinski at gmail.com> wrote: > I'm looking currently into a patch >

This is just a note to mention that LLI will now correctly simulate the endianness of the target machine (it's configured for sparc right now, which is big endian), despite the fact that the machine you're running lli on may be of different endianness (for example little endian on x86). This fixes the last problem that I know of where running lli on x86 produces results that are different

Finally lli and llvmgcc can work under my directory. I wrote the following simple program and compiled it using gcc and then run it without any problem. But when I tried to compile it using llvmgcc and lli, llvmgcc gave me the following error message which I cannot understand: xli3|csil-suna37|~/cs426|[181]% llvmgcc test.c -o test test.c: In function `init': test.c:10: warning: cast to

lli executed the bytecode corresponding to test_3.0_ml.ll without a failure, even though Function() is accessing an invalid memory address. The original code is in test_3.0.c, and the malloc() in Create() has been replaced by alloca() in test_3.0_ml.ll. I expected lli to segfault or similar when testing my code. Are my assumptions erroneous? -------------- next part --------------

When you run a program foo linked with gccld (i.e., by running the script "foo" it outputs which runs lli) it passes foo.bc instead of foo as the argv[0] for the program. This is surprising to the user, who is expecting that a program started by running "./foo" will call itself "./foo", not "./foo.bc". Fixed by removing ".bc" from the end of

On Thu, Oct 07, 2004 at 06:22:34PM -0400, Shukang Zhou wrote: > I am working with llvm 1.3 on a sparcv9 machine. I have successfully > built llvm and llvm-gcc frontend. I can run many tools including > llvmgcc, llvm-dis, and llc. After using /opt/SUNWspro/bin/cc to > assemble .s file into a program binary, I can run the binary correctly > as well. > > I am interested in the

On Thu, Oct 07, 2004 at 06:46:18PM -0400, Shukang Zhou wrote: > Thanks Misha. I tried the "gcc -dM -E /tmp/file.c | grep __sparcv9" > but there was no output. Maybe this is the probelm, I do have > > CXX = g++ -mcpu=v9 > CC := gcc -mcpu=v9 > > in the Makefile.config. Do I need to add -m64 as well? Thanks. Just run the test that I mentioned before: > On Thu, 7

I'm sorry, I did not completely understand your email, let me clarify my response. On Thu, Oct 07, 2004 at 06:46:18PM -0400, Shukang Zhou wrote: > Thanks Misha. I tried the "gcc -dM -E /tmp/file.c | grep __sparcv9" > but there was no output. Maybe this is the probelm, I do have > > CXX = g++ -mcpu=v9 > CC := gcc -mcpu=v9 > > in the Makefile.config. Do I need

I forgot that lli was "special". It uses the "JIT" keywoard which means "figure out the right libraries to use for a JIT compiler and runtime". So, just add this, to tools/lli/Makefile: USEDLIBS := LLVMBCWriter That worked for me. Reid. On Thu, 2005-02-24 at 16:58, Patrick Meredith wrote: > Where do I add that line? Just putting it in the vanilla Makefile in

Yikes, my tree must be more outdated than I thought. My library is still called bcwriter. Unfortunately when I add that line I get even more errors, seems like the only solution is going to be updating everything ;-) ----- Original Message ----- From: "Reid Spencer" <reid at x10sys.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday,

Hello (again), I was perusing the nightly tests and looking at the code performance ratios, etc. The worst case I saw was the C++ Shootout benchmark for lists. After some disentangling of the nightly test scripts, I ran the llc version through valgrind to see where the performance bottleneck is, but the results don't include debugger symbols, and the output is useless. I tried using -g

The attached patch makes lli link with selectiondag. Without it I get a link error. Best Regards, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch Type: application/octet-stream Size: 589 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060904/5556928c/attachment.obj>

How does threading work in lli, particularly in interpreted (non-JIT) mode? I've tried to find direct references in the code and couldn't, so am I right in assuming that it's expected that any underlying OS's threading will be used? If so, how does this work with respect to (I assume) needing to maintain explicitly separate execution context stacks for each thread? Thanks,

On Wed, 25 Oct 2006, Sarah Thompson wrote: > Is there any way to support calling external libraries from interpreted > code (*not* JITted code) within lli? Sure. > I am looking at the external functions implementation, and it seems just > to wrap back onto its own library, looking up lli_X_... prefixed > functions. It would (for obvious reasons) be incredibly useful not to be >

Chris Lattner wrote: > > The JIT has a superset of this functionality. However, if there is JIT > support for the host that you are interested in, you shouldn't have to use > the interpreter at all. > > For interpreting, yes, but model checking is weirder so it's greatly beneficial to be able to heavily hack an interpreter. >> I can't really move to using