similar to: [LLVMdev] Data Layout in Stack (Optimization)

Hi, Does LLVM do any automatic data layout in the stack to optimize cache line use or prefetch ? (Not referring to user inserted prefetch directives). I.e. Is the ordering of my calls to `CreateAlloca` rearranged? If yes, is there some doc on it? Thanks, Bob Floyd -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi All, we have an issue with our LLVM-based JIT compiler - executing the compiled code corrupts memory (and subsequently crashes) if we alloca more than 4k of variables (more than 511 8-byte ints). The same code works on Windows 7 (32 and 64 bit), Linux, MacOS. We compile LLVM and our program with Microsoft's Visual Studio 2010. Both debug and release builds are affected. The variables

We tested on 3.4.2 and 3.5.1. Later versions are slightly problematic to test since they don't compile with VS2010. Do you happen to know if it's fixed in one of the released versions, or if there is a workaround (chkstk?) or a bug report online? Thanks! Eph On 30.06.2015 12:58, Nicholas Chapman wrote: > It's a known issue. I believe it's fixed in trunk however. >

I just added support for arrays to the front-end for a trading-specific DSL that I'm implementing using LLVM and ran into a minor bump. Internally, I have been treating variables the same whether they end up being GlobalVariables or stack variables allocated with Alloca. I store the Value* I get from CreateAlloca or the Value* I get when I create a new GlobalVariable into my symbol table when

On Sun, Jul 16, 2017 at 06:00:45AM +0000, Lior Narkis wrote: > > -----Original Message----- > > From: virtio-dev at lists.oasis-open.org [mailto:virtio-dev at lists.oasis-open.org] > > On Behalf Of Michael S. Tsirkin > > Sent: Wednesday, February 08, 2017 5:20 AM > > To: virtio-dev at lists.oasis-open.org > > Cc: virtualization at lists.linux-foundation.org >

Hi, I'm using IR and MCJIT to compile a script language. I debug it with on the fly generated .pdb files. During debugging, almost each time I step into a function, I loose information about calling function inside the visual studio callstack view or I have a bunch of pure addresses in the callstack in between the current function and the calling function, for example :

Is there a recommended way to retrieve the original type from an AllocaInst object? For example, I am creating alloca instructions using the IRBuilder interface like: alloca = builder.CreateAlloca( Type::getDoubleTy( context ), 0, variableName.c_str() ); and I place the alloca into a symbol table. Later when I am generating instructions for an assignment operation, I want to check the type of

Curtis Faith wrote: > Is there a recommended way to retrieve the original type from an > AllocaInst object? > > For example, I am creating alloca instructions using the IRBuilder > interface like: > > alloca = builder.CreateAlloca( Type::getDoubleTy( context ), 0, > variableName.c_str() ); > > and I place the alloca into a symbol table. > > Later when I am

You should be able to use the second alternative that Nick proposed: cast<PointerType*>(pointer_value->getType())->getElementType() Reid On Fri, May 28, 2010 at 9:37 AM, Curtis Faith <curtis at curtisfaith.com> wrote: > Thanks Nick, > Unfortunately, that is indeed what I asked for but not what I really am > looking for. > My naive approach is to store symbol table

Hi, First, considering I'm using an IRBuilder and a DIBuilder to build my program, how can I automatically bind the CreateAlloca with my named local variable inside the DIBuilder ? Is it automatic with the Twine name of CreateAlloca ? And/Or should I use DIBuilder::createAutoVariable and how ? Then, I'm wondering how to locate back my local variable in memory (register or stack) once i

Thanks Nick, Unfortunately, that is indeed what I asked for but not what I really am looking for. My naive approach is to store symbol table entries as Value* objects so I can allocate global variables and alloca variables and place them into the symbol table and the rest of the code didn't need to know which kind they were, in general. Loads and Stores of these types (as well as other

"IR" often refers to the general concept/semantics, not only the textual format in .ll files (there are 3 main forms - bitcode, textual IR, and the in-memory representation (llvm::Module, etc - constructed using IRBuilder)). A great place to start is to look at what Clang does to produce debug info - it uses IRBuilder, for instance. So you could look at how Clang uses the IRBuilder when

Hi Paul, How can i make this call to intrinsic from the c++ code ? I'm not working with the IR language, but directly in C++ with IRBuilder::CreateAlloca. My goal is that one : - Generate machine code with an instance of the class 'IRBuilder' - Emit 'ObjFile' class instance with MCJIT - Create a DwarfContext instance directly from the emitted ObjFile object

Binding the alloca to the debug-info metadata is not automatic. You need to emit an intrinsic function call to llvm.dbg.declare to bind the two together. If you are simply trying to emit DWARF for your program, the rest of the processing should already be in place for that. If you are trying to do something else, you would need to describe that so we understand what you need. --paulr From:

CreateAlloca(Type) returns an object of type Type*, the memory that can hold an object of type Type. You probably don't want to be creating allocas just before calling the function since 1) if that call winds up in a loop they'll grow your stack frame without bound, and 2) the memory they point to is initially uninitialized. Where did the tutorial tell you to do that? In general, when I

> -----Original Message----- > From: Michael S. Tsirkin [mailto:mst at redhat.com] > Sent: Tuesday, July 18, 2017 7:23 PM > To: Lior Narkis <liorn at mellanox.com> > Cc: virtio-dev at lists.oasis-open.org; virtualization at lists.linux-foundation.org > Subject: Re: [virtio-dev] packed ring layout proposal v2 > > On Sun, Jul 16, 2017 at 06:00:45AM +0000, Lior Narkis

> -----Original Message----- > From: Michael S. Tsirkin [mailto:mst at redhat.com] > Sent: Tuesday, July 18, 2017 7:23 PM > To: Lior Narkis <liorn at mellanox.com> > Cc: virtio-dev at lists.oasis-open.org; virtualization at lists.linux-foundation.org > Subject: Re: [virtio-dev] packed ring layout proposal v2 > > On Sun, Jul 16, 2017 at 06:00:45AM +0000, Lior Narkis

>I'm currently facing the same problem. >I added the libFLAC++ libraries to my MSVC application. >I implemented the same quality levels (0-8) as used in the FLAC frontend application. >But the resulting files are remarkable different between my application and the FLAC frontend >(although using the same settings). It did turn out to be something in my byte ordering in the end

On Oct 18, 2011, at 2:53 AM, Chandler Carruth wrote: > Hello, > > I'm working on basic-block placement optimizations based on branch probability information. I've run into a stumbling block though. One of the existing passes to do this, essentially a dead pass 'block-placement' operates on the IR, reordering the blocks of the function, and relying on the code generator

> -----Original Message----- > From: virtio-dev at lists.oasis-open.org [mailto:virtio-dev at lists.oasis-open.org] > On Behalf Of Michael S. Tsirkin > Sent: Wednesday, February 08, 2017 5:20 AM > To: virtio-dev at lists.oasis-open.org > Cc: virtualization at lists.linux-foundation.org > Subject: [virtio-dev] packed ring layout proposal v2 > > This is an update from v1