similar to: A pass which moves AllocaInst into function entry block?

Even if I turn to -O0 [in other words, no optimisation passes at all], it takes the same amount of time. The time is spent in 12.94% lacsap lacsap [.] llvm::SDNode::use_iterator::operator== 7.68% lacsap lacsap [.] llvm::SDNode::use_iterator::operator* 7.53% lacsap lacsap [.] llvm::SelectionDAG::ReplaceAllUsesOfValueWith 7.28% lacsap

Hi, My requirement is something like as given below, a.c => a.obj contains a1() and a2() function b.c => b.obj contains b1() and b2() function main.c => main.obj call to a1, a2, b1, b2 Now, I want to move a1(), a2() from a.obj to b2.obj and on top of function b1() When I call b1() from main, it should call first a1, a2 and then function definition of b1 Can you please give me some

Hi, Yes I am looking for IR pass that will do insert call of functions that defined in another file. Links/suggestions that guide me to start for adding IR pass will help me so much. Regards, Deepika On Wed, Feb 10, 2016 at 1:03 PM, mats petersson <mats at planetcatfish.com> wrote: > So how do you know what you want to modify (conceptually)? > > Have you got a IR pass that you

I've definitely "run into this problem", and I would very much love to remove my kludges [that are incomplete, because I keep finding places where I need to modify the code-gen to "fix" the same problem - this is probably par for the course from a complete amateur compiler writer and someone that has only spent the last 14 months working (as a hobby) with LLVM]. So whilst

Hi everyone, We have noticed that the SROA pass will only eliminate 'alloca' instructions if those are located in the entry basic block of a function. As a general recommendation, should the LLVM IR emitted by our compiler always place 'alloca' instructions in the entry basic block ? (I couldn't find any recommendations concerning this matter.) In addition, we have noticed

Hi, I want to call/add some functions(that defined in another file) on top of some functions, and reflect the same changes in object file. No, I am not looking for contractor. Thanks, Deepika On Tue, Feb 9, 2016 at 7:04 PM, mats petersson <mats at planetcatfish.com> wrote: > What is the condition for adding this code? > > What have you tried so far? [Or are you looking for a

Hello, Hopefully this is the correct place for this sort of question. I have been trying to do some simple instrumentation of LLVM IR, and I have been confused by the return type of alloca. When passing an AllocaInst as a parameter to a function call, the parameter type is i32**, which is not what I would expect. Really I would like the address of the allocated memory. What am I missing? And is

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

From: Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> Date: mardi 8 septembre 2015 12:50 To: Benoit Belley <benoit.belley at autodesk.com<mailto:benoit.belley at autodesk.com>>, "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject:

Hi, I'm trying to get my head around c++ - IR - c++ API and getting used tramform manual information to code. The manual states alloca is defined for <type>. FunstionType is a type, so alloca for functionType should be possible? Not? If we have a valid Module *m we can get an allocate instruction allocating space for a non-argumented function as follows: AllocaInst* pa2 = new

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

Hi Mats, It's private backend. I will try describing what I am dealing with. struct S { unsigned int a : 8; unsigned int b : 8; unsigned int c : 8; unsigned int d : 8; unsigned int e; } We want to read S->b for example. The size of struct S is 64 bits, and seems LLVM treats it as i64. Below is the IR corresponding to S->b, IIRC. %0 = load

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

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

I would like to get feedback from the community on how I can speed up the compilation of a function that has one huge basic block consisting of over 150K instructions. It takes about 10 minutes for clang to produce the object file and the function that is taking up the majority of the time is LoadAndStorePromoter::run, which is called when SROA is run: // Otherwise, we have mixed loads and

> Hmmm... wouldn''t it be nice if we didn''t have a bespoke, > buggy & incomplete emulator for hvm mmio. ;-) In the process of solving this one, I''ve got to (another) of the blocking points... At the moment, we translate the virtual address from the guest in the page-fault-handler to guest physical address via the gva_to_gpa() function in svm.c/vmx.c:

I have written many builtins for our SHAVE processor which bind directly to our instructions, and making instructions that are not easily selectable by the compiler available to the programmer. The majority of these are straight-forward enough, taking a small number pf input operands and returning a single result; for example 'int __builtin_shave_mul(int, int)' might map onto a simple

On Thu, May 15, 2014 at 9:31 AM, Philip Reames <listmail at philipreames.com>wrote: > On 05/14/2014 06:02 PM, Akira Hatanaka wrote: > > I would like to get feedback from the community on how I can speed up > the compilation of a function that has one huge basic block consisting of > over 150K instructions. It takes about 10 minutes for clang to produce the > object file

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

Hi, I am working to improve SROA to generate better code when a method has a struct in its arguments. I would appreciate it if I could have any suggestions or comments on how I can best proceed with this optimization. * Problem * I observed that LLVM often generates redundant instructions around glibc’s istreambuf_iterator. The problem comes from the scalar replacement (SROA) for methods with an