similar to: [LLVMdev] Is bitcast now needed in LLVM?

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

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? I effectively have emit some sort of binary op codes to be passed into llvm right? The same thing for if I wanted to integrate a GC? Could the interfacing be done in any other language? -------------- next part -------------- An HTML

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

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

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

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

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, In PromoteMemoryToRegister.cpp, it seems to rely on the fact that the only users of bitcast/GEP instruction are lifetime intrinsics (llvm.lifetime.start/end). I did some searching in llvm/test folder, it seems to be true. However, by reading LLVM IR manual, I don't see any restriction stated on the possible user of bitcast/GEP instruction. So my question is who impose the restriction ?

Hi everyone, This is a simple question but is there an efficient way to get the *value for casting* directly from a bitcast instruction? bitcast format :<result> = bitcast <ty> <*value*> to <ty2> For example, if i have MemAddr ... 0x3d61238 %key = alloca [16 x i8], align 16 0x3d612a8 %plain_text = alloca [64 x i8], align 16 0x3d61318 %key1 = bitcast [16 x i8]*

So, you need to bitcast `pinst` to a pointer to Vector of double, since it (I hope for your sake) is a pointer to integer. What you are trying to do is bitcast a pointer into a vector, which probably will lead to an assert or "bad code that doesn't work". -- Mats On 15 April 2015 at 21:57, zhi chen <zchenhn at gmail.com> wrote: > What I want to do is to change the pInst

Dear LLVM, This is probably a question for Fortran/DragonEGG experts: Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ? Why it needs bitcast? I'm expecting something like "call void @_gfortran_flush_i4(i8* null)". Otherwise, we will need to teach our call parsers to digg

This might help: http://llvm.org/docs/ProgrammersManual.html#the-value-class Or maybe I'm misunderstanding what you mean by "efficient way to get the value". When you say 'value', I'm assuming you mean the class. In your case, AllocaInst inherits from value. -Ryan On Thu, Dec 15, 2016 at 10:24 AM, Shen Liu via llvm-dev < llvm-dev at lists.llvm.org> wrote: >

How can I write code to generate IR for: %2 = bitcast double* %1 to <2 x double>*. %3 = load <2 x double>* %2, align 16 Basically, it is similar to x86 _mm_load_pd1 intrinsics. Thanks, Zhi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150415/66489860/attachment.html>

I have a little simple inheritance thing going on: %struct.PDFrame = type { i64, i64, i8* } %struct.PDField = type { %struct.PDFrame, i8 } Is there any difference between bitcasting a pointer to the struct.PDField to struct.PDFrame, or using GEP to get a pointer to the "super" struct? I'm not even sure it's possible to bitcast in this situation, but I imagine it should be. --

On 17/07/12 08:22, Anton Korobeynikov wrote: > Dmitry, > >> This is probably a question for Fortran/DragonEGG experts: >> >> Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* >> @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ? Why it needs >> bitcast? > Just a wild guess (basing from my llvm-gcc