similar to: [LLVMdev] writing llvm ir not in c++

On 10/13/14 11:44 AM, Eli Bendersky wrote: > On Mon, Oct 13, 2014 at 10:35 AM, Dave Pitsbawn <dpitsbawn at gmail.com> wrote: > >> Is it possible to write LLVM IR but not using C++? >> >> I'm exceedingly terrible at C++. >> >> I was thinking, isn't it possible to write the IR using Java? >> > > > You can use llvmpy (Python bindings

I always thought that bitcast was a no-op internal llvm thing to fit the IR type system. I currently use sitofp, but I see your point. On Fri, Apr 17, 2015 at 1:04 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi Dave, > > You can still bitcast between i32 and float, for example. > > Cheers, > > James > > On Fri, 17 Apr 2015 at 09:03 Dave Pitsbawn

I generally see an announcement on the list for the social events .. but I haven't seen one yet for June. It will be my first social if we're having this. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150601/630af906/attachment.html>

Thanks, Andy. I'm now thinking about the case where the generated code has references to memory addresses in the IR (the only case I suppose is call remoteProcessADDR). I know this is not LLVM specific but what happens when that ADDR changes due to process restart or different machine. I know this is the clients responsibility to put the right address in the call instruction, but generally

Seems like a new change in LLVM has made it so that bitcast of bitcast i8* %1 to %Foo* meaningless? If I'm correct is there any need for the bitcast anymore? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150417/e5bfbc64/attachment.html>

No, I was asking how to extract the code from MCJIT, and you said it use a custom memory manager. When you say that I must treat each section as a block, do you mean that there is inter-block relative offsets need to be maintained? Or that when I get a section, I must copy it to target process memory as a one-shot contiguous block. If it's second, I think we're ok. On Wed, Mar 25, 2015

I recently saw a post about being able to call LLVM APIs from .NET using a C# library. I'm thinking if it'll produce the same code as using the LLVM C++ API. Will it be less efficient? If it is the same why wouldn't every one use a higher level language like C# or Java to write their compiler? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Aha. Thanks. Seems like I need to call mapSectionAddress with the target address. But how I copy the code? What function would I call? On Wed, Mar 25, 2015 at 4:32 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Yes, that is one of the intended use models for MCJIT. > > > > If you look at the source for ‘lli’ you’ll find an option called > “remote-mcjit” which

Thanks all. David why do you say it is particularly bad IR (other than not having gone through SROA). Is it the multiple blocks for early returns? That is how I'm supporting early returns in the middle of a basic block. I couldn't find any other way. On Sun, Apr 5, 2015 at 6:24 AM, David Jones <djones at xtreme-eda.com> wrote: > Data point: > > I use (rarely) alloca in

Here is some IR that is working and executing as expected -- All allocas are in the first basic block, and only updates happen in other basic blocks. define i32 @f() { entry: %x = alloca i32 store i32 333, i32* %x %i = alloca i32 store i32 11, i32* %i br i1 true, label %if.then, label %if.else if.then: ; preds = %entry store i32 3, i32* %i

It's not great IR, but it doesn't look like it should actually crash, just (without SROA) produce comparatively bad code. The alloca is only referenced in the basic block that it exists. If this isn't expected to work, then we should probably improve the documentation of alloca in the language reference. David > On 5 Apr 2015, at 04:55, Eric Christopher <echristo at

Hello all, Does anyone have any inside why I can't get the below simple C API test to link? This is on a 32-bit Gentoo Linux system and LLVM TOT which was compiled with enable-optimized, gcc is 4.3.2. 15:26|melis at juggle2:~/c/llvmpy> cat t.c #include "llvm-c/Core.h" int main() { LLVMContextRef ctx; ctx = LLVMContextCreate(); return 0; } 15:29|melis at

Don't you have the same problem with other atoms, e.g. variable names? This sounds like something that should be implemented in the language's runtime library. On May 4, 2014 7:15 PM, "Alexander Popolitov" <popolit at gmail.com> wrote: > Hi everyone! > > I'm trying to implement lisp's funcall function, which roughly calls a > function, name of which

"Paul Melis" <llvm at assumetheposition.nl> writes: > 15:29|melis at juggle2:~/c/llvmpy> gcc -W -Wall -o blah `llvm-config --cflags > --ldflags --libs all` t.c > /tmp/ccs4MbKp.o: In function `main': > t.c:(.text+0x21): undefined reference to `LLVMContextCreate' > collect2: ld returned 1 exit status > > 15:29|melis at juggle2:~/c/llvmpy> nm

A need has arisen to generate code using MCJIT but not in the target process instead in a different process (and possibly even different machine though not in the scope). Reading through the tutorials and MCJIT design document, it seems like this is possible or was kept in mind during design of MCJIT. How do I achieve this? Are there examples? Dave -------------- next part -------------- An

In my language there are a lot of i16 definitions, but almost all of the time they are upgraded to i32 because my add operations only happen on i32. So to be representative to my language definition, I have a lots of Sext/Zext and Truncs pretty much every time I add or subtract. As soon as I pass through InstCombine things look much nicer, all the upcasts and downcasts go away, but my test cases

Hi, I've updated the Python LLVM bindings for LLVM 1.5 (attached). I also thought of setting up a CVS repository for this, but before I do that I thought I'd ask if you want to take the Python bindings to the main LLVM CVS? I noticed that the C language bindings would be maintained there. Changes in Python-LLVM: - Updated to match LLVM 1.5 API - Added Windows build support (created

Hi Jarno, This is great! We would absolutely love to have python bindings for LLVM. From the look of your patch, I think we want this to become an LLVM project since it has configuration and compiler support that is new to the main LLVM repository. We don't want the main LLVM libraries to be dependent on Boost or Python. So, there's a couple things we need to have you do before this

Hi, some discussion below. Reid wrote: > 3. Fix your Makefile to build a shared library properly. You have set > TOOLNAME which is for building an executable tool not a shared > library. You need to set LIBRARYNAME=..., not TOOLNAME=... I remember having failed to build a functioning Python extension module with LIBRARYNAME and SHARED_LIBRARY flags. Anyway, I cannot remember

Hi, I wrote yet another [1,2] Python binding for LLVM! I'm doing this because llvmlite has some serious limitations: 1) it cannot parse an existing IR, only create new modules [3], 2) it keeps its own representation of the IR (which is less memory efficient than the LLVM one), and 3) each llvmlite version supports a single LLVM version. Considering that my need is to load modules of hundreds