search for: addcommoncodegenpass

Displaying 20 results from an estimated 32 matches for "addcommoncodegenpass".

Did you mean: addcommoncodegenpasses
2011 Feb 24
0
[LLVMdev] CodeGenOpt
...able? >> >> I don't think that this is the right way to go. Higher level >> decisions like that should affect your choice of passes to schedule. > > But there's no way to do that at the codegen level. LLVMTargetMachine > keys off of CodeGenOpt. If you look at addCommonCodeGenPasses() then you'll see that CodeGenOpt is not used to select passes. Yes, CodeGenOpt::None is checked at few places to ensure that we are doing optimization, but it is not checking *level* of optimization. If seems you want better approach to influence pass selection in addCommonCodeGenPasses()...
2011 Feb 24
2
[LLVMdev] CodeGenOpt
Chris Lattner <clattner at apple.com> writes: >> class CodeGenOpt { >> ... >> public >> getOptLevel() ...; >> getFPLevel() ...; >> getMemLevel() ...; >> }; >> >> Does this sound reasonable? > > I don't think that this is the right way to go. Higher level > decisions like that should affect your choice of passes to
2011 Sep 19
1
[LLVMdev] Seg Fault when creating an execution engine
...ngine using the LLVMCreateExecutionEngineForModule function from the C API. I am get a set fault with the following backtrace. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000120 0x0000000107c06643 in llvm::LLVMTargetMachine::addCommonCodeGenPasses () (gdb) bt #0 0x0000000107c06643 in llvm::LLVMTargetMachine::addCommonCodeGenPasses () #1 0x0000000107c05c6b in llvm::LLVMTargetMachine::addPassesToEmitMachineCode () #2 0x0000000107ead7ab in llvm::JIT::JIT () #3 0x0000000107eaac21 in llvm::JIT::createJIT () #4 0x0000000107e2cbe4 in llvm::E...
2011 Jun 06
0
[LLVMdev] Understanding SelectionDAG construction
Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]
2011 Jun 06
4
[LLVMdev] Understanding SelectionDAG construction
I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc
2009 Jun 17
1
[LLVMdev] Undocumented API changes
...ing llvm_start_multithreaded(). Please begin to update your client applications now if this affects you, as I will be throwing the switch in SVN sooner rather than later. 3. The change you should make: every call to addPassesToEmitFile, addPassesToEmitFileFinish, addPassesToEmitMachineCode, or addCommonCodeGenPasses should pass an optimization level enum rather than true / false for "Fast". The enum is in llvm/Target/TargetMachine.h: namespace CodeGenOpt { enum Level { Default, None, Aggressive }; } 4. The LLVM IR opcodes Add, Sub, and Mul have been each split into two. Add,...
2010 Apr 14
2
[LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions
I've recently sync'd to a newer version of LLVM(Apple branch 2326 from Apple branch 2323.8) that changed the interface to addCommonCodeGenPasses which caused the default implementation to be executed instead of my overriding implementation. This default implementation has DeadMachineInstructionElim pass enabled, which is causing havoc with my backend. Before entering this pass, everything in my machine function is fine, after this pass, a...
2010 May 18
1
[LLVMdev] Fast register allocation
...oc goes with fast-isel. But perhaps we could take this opportunity to let LLVMTargetMachine choose a register allocator based on the optimization level? It is already enabling fast-isel that way, and -O0 -regalloc=linearscan (which is the default) doesn't really make sense. LLVMTargetMachine::addCommonCodeGenPasses does a decent job of building a codegen pipeline, except it needs help picking a register allocator. There is no good reason for that. /jakob
2011 Oct 18
3
[LLVMdev] Fixing segmented stacks
...irst of all, sorry for the delay. This about fixing the issue with having a the BB ending with a non-terminating instruction when compiling with segmented stacks. I'm not sure if having an isel pseudo instruction which is lowered into a RET and then a MOV would work better. LLVMTargetMachine::addCommonCodeGenPasses adds the ExpandISelPseudosPass before the PEI pass (so it boils down to the same thing, I think -- the verifier will still complain). This is, of course, assuming I understood Duncan correctly. The only fix I can think of is splitting the thing into two separate basic blocks. I already have se...
2009 Jun 22
4
[LLVMdev] Adding safe-point code generation
...tion.html#collector-algos points out that there's no way to emit code at safe points yet, and there are no loop safe points at all. So I'll be trying to implement them. Is there anything I should know before starting? One way to do this might be to add a FunctionPass to LLVMTargetMachine::addCommonCodeGenPasses() alongside createGCLoweringPass(), which would insert user-defined code for safe points. Unfortunately, code inserted there would stick around in the IR after the machine code was emitted, and if the function were JITted again, we'd get duplicate safe points. Another way to do it might be t...
2009 Jun 17
10
[LLVMdev] Segmentation fault - Kaleidoscope
On Jun 17, 2009, at 9:46 AM, Paul Melis wrote: > FWIW, I'm also suddenly experiencing segfaults in code that used to > work > a few days ago (I'm using svn). This may be unrelated to the problem > described below, but perhaps it's the same thing. > > In my case it seems that creating an ExecutionEngine has changed. I > used > to do > > Module* Mod
2009 Feb 23
0
[LLVMdev] Creating an LLVM backend for a very small stack machine
...get a stack machine? You should be able to use existing LLVM backend code and TableGen at least through instruction selection; I'm not sure whether you'll want register allocation or not, but it should be easy to choose either way. The whole thing is quite flexible; see LLVMTargetMachine::addCommonCodeGenPasses in lib/CodeGen/LLVMTargetMachine.cpp for a high-level overview of how CodeGen works. It might also be useful to look at LLVM handles x87 floating-point; the relevant code is in lib/Target/X86/X86FloatingPoint.cpp. > * When/where/how do things like big integer (iXXXXX), phi nodes, llvm.* &gt...
2010 Apr 14
0
[LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions
On Apr 14, 2010, at 1:55 PMPDT, Villmow, Micah wrote: > I’ve recently sync’d to a newer version of LLVM(Apple branch 2326 from Apple branch 2323.8) that changed the interface to addCommonCodeGenPasses which caused the default implementation to be executed instead of my overriding implementation. This default implementation has DeadMachineInstructionElim pass enabled, which is causing havoc with my backend. Before entering this pass, everything in my machine function is fine, after this pass, a...
2011 May 17
1
[LLVMdev] TargetRegisterInfo and "infinite" register files
...t; I plan on eventually implementing both and seeing which works best for different types of input. > > If virtual registers are used, how do you disable final register allocation in the back-end? If post-RA passes have trouble with virtual registers, you probably need to implement your own addCommonCodeGenPasses() method. Alternatively, implement a trivial register allocator that simply runs 2-addr, phi-elim, and coalescing. > Looking through the different Target* classes, I do not see any way to disable it. I imagine the TargetRegisterClass implementations are still needed to determine legal virt...
2010 Jul 21
0
[LLVMdev] MC-JIT
...tMC(PassManagerBase &PM, + MCContext *&Ctx, + CodeGenOpt::Level OptLevel, + bool DisableVerify) { Args above should be aligned with column after opening paren. + // Add common CodeGen passes. + if (addCommonCodeGenPasses(PM, OptLevel, DisableVerify, Ctx)) + return true; + // Make sure the code model is set. + setCodeModelForJIT(); + + return false; // success! +} + -void MCAssembler::Finish() { +void MCAssembler::Finish(MCObjectWriter *Writer_) { Why two variables Writer_ and Writer? I don't know of...
2010 Apr 14
2
[LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions
...v at cs.uiuc.edu Subject: Re: [LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions On Apr 14, 2010, at 1:55 PMPDT, Villmow, Micah wrote: I've recently sync'd to a newer version of LLVM(Apple branch 2326 from Apple branch 2323.8) that changed the interface to addCommonCodeGenPasses which caused the default implementation to be executed instead of my overriding implementation. This default implementation has DeadMachineInstructionElim pass enabled, which is causing havoc with my backend. Before entering this pass, everything in my machine function is fine, after this pass, a...
2010 Jul 20
2
[LLVMdev] MC-JIT
New patch taking Eli's comments into account. Olivier. On Tue, Jul 20, 2010 at 11:09 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Jul 20, 2010 at 1:36 PM, Olivier Meurant > <meurant.olivier at gmail.com> wrote: >>> Seems reasonable, but I haven't looked at the code yet. I would >>> suggest trying to split your work up into separate
2009 Apr 30
0
[LLVMdev] Change in JIT
...whether you wanted "fast" code generation or normal code generation. Now, we have a finer-grained control over this. An enum value is passed instead of a boolean flag. The change you should make: every call to addPassesToEmitFile, addPassesToEmitFileFinish, addPassesToEmitMachineCode, or addCommonCodeGenPasses should pass an optimization level enum rather than true / false for "Fast". The enum is in llvm/Target/TargetMachine.h: namespace CodeGenOpt { enum Level { Default, None, Aggressive }; } The "Default" enum is the old, non-fast version. "None" is now...
2010 May 18
0
[LLVMdev] Fast register allocation
You mention some potential issues on ARM, should we sort those out before we enable it in Clang? It's somewhat more convenient to have things be consistent. I propose that at some point you just replace the old local register allocator with the new one, and rename the old one. Then clients don't need to change, and we can keep the old one available for a little while if we want, for
2011 May 30
0
[LLVMdev] how to emit machine code to custom MCStreamer
Hi! I'd like to emit code to a custom MCStreamer instead of e.g. MCELFStreamer. Unfortunately LLVMTargetMachine::addCommonCodeGenPasses is private but I would need it, or even better a method simular to addPassesToEmitFile (e.g. addPassesToEmitCustomMC) taking an MCSreamer would be great. What do you think? -Jochen