search for: codegenpass

> On 25 May 2018, at 01:46, Aaron via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > LLVM optimization pass gives an error "Terminator found in the middle of a basic block!" since basic block IR may have multiple "ret" instructions. It seems LLVM does not accept multiple return in a basic block by default. > Yes, if you’re inserting

Hi all, LLVM optimization pass gives an error "Terminator found in the middle of a basic block!" since basic block IR may have multiple "ret" instructions. It seems LLVM does not accept multiple return in a basic block by default. Is there a specific optimization or pass that I can enable to remove unreachable codes in basic blocks? Best, Aaron -------------- next part

...br instruction creation lines. >> Just curious, how are you getting return instructions in the middle of a basic block? My code generation pass allows multiple return instruction generation since that simplifies front-end significantly. Here is the code if anyone would like to use it: void CodeGenPass::DeleteDeadCode(llvm::BasicBlock * basicBlock) { for (auto it = basicBlock->begin(); it != basicBlock->end(); ++it) { // Split after first return instruction. if (it->getOpcode() == llvm::Instruction::Ret) { ++it; // Split only if the...

...iagnostic for some condition? How would this work? Would you have clang insert extra passes to check for various conditions that might require diagnostics? I don't see how else you would do it, since clang's interface to the backend just sets up the PerFunctionPasses, PerModulePasses and CodeGenPasses pass managers and then runs them. Assuming you did add some special passes to check for problems, wouldn't those passes have to duplicate a lot of effort in some cases to find the answers? Take for example the existing warnings in IntrinsicLowering::LowerIntrinsicCall. Those badly need to...

...iagnostic for some condition? How would this work? Would you have clang insert extra passes to check for various conditions that might require diagnostics? I don't see how else you would do it, since clang's interface to the backend just sets up the PerFunctionPasses, PerModulePasses and CodeGenPasses pass managers and then runs them. Assuming you did add some special passes to check for problems, wouldn't those passes have to duplicate a lot of effort in some cases to find the answers? Take for example the existing warnings in IntrinsicLowering::LowerIntrinsicCall. Those badly need to...

Thanks for your last reply. Could I understand the way to adding a pass (built into the llvm rather than dynamic loadable) includes: 1. Declaring a creator function for this pass 2. Implementing the creator function for this pass 3. Instantiating this pass and get a object of it 3. Register this pass into the PassRegistry Then, for a built-into bytecode pass, task 1(declaration of the

...iagnostic for some condition? How would this work? Would you have clang insert extra passes to check for various conditions that might require diagnostics? I don't see how else you would do it, since clang's interface to the backend just sets up the PerFunctionPasses, PerModulePasses and CodeGenPasses pass managers and then runs them. Assuming you did add some special passes to check for problems, wouldn't those passes have to duplicate a lot of effort in some cases to find the answers? Take for example the existing warnings in IntrinsicLowering::LowerIntrinsicCall. Those badly need to...

...iagnostic for some condition? How would this work? Would you have clang insert extra passes to check for various conditions that might require diagnostics? I don't see how else you would do it, since clang's interface to the backend just sets up the PerFunctionPasses, PerModulePasses and CodeGenPasses pass managers and then runs them. Assuming you did add some special passes to check for problems, wouldn't those passes have to duplicate a lot of effort in some cases to find the answers? Take for example the existing warnings in IntrinsicLowering::LowerIntrinsicCall. Those badly need to...

...artition *P = _IPOPartMgr.CreateIPOPart(mergedModule); + P->SaveBitCode(); + } +} + +bool LTOCodeGenerator::performPostLTO(Module *Mod, formatted_raw_ostream &Out, + std::string &errMsg) { + // placeholder for post-IPO scalar opt + PassManager codeGenPasses; codeGenPasses.add(new DataLayout(*_target->getDataLayout())); _target->addAnalysisPasses(codeGenPasses); - formatted_raw_ostream Out(out); - // If the bitcode files contain ARC code and were compiled with optimization, // the ObjCARCContractPass must be run, so do it uncon...

On Tue, Jul 16, 2013 at 9:34 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> > wrote: > > ** Advices Needed ** > > 1. Decide whether or not we want such capabilities (if we do not we may >

On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> wrote: >> ** Advices Needed ** >> >> 1. Decide whether or not we want such capabilities (if we do not we may just >> add sporadically the support for a new warning/group of warning/error). >> 2. Come

...ModulePass' /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:364: error: `FunctionPassManager' was not declared in this scope /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:364: error: `PM' was not declared in this scope /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:371: error: `CodeGenPasses' was not declared in this scope /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:372: error: expected type-specifier before `FunctionPassManager' /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:372: error: expected `;' before `FunctionPassManager' /projects/compiler/llvm-gcc/gc...

----- Original Message ----- > From: "Keno Fischer via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Morten Brodersen" <Morten.Brodersen at constrainttec.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, February 4, 2016 6:05:29 PM > Subject: Re: [llvm-dev] MCJit Runtine Performance > > > > Yes,