search for: x86passconfig

...re getting ready to implement several heuristics for correctly using LEAs to avoid stalls in the address generator on Atom. Our plan is to: 1. Disabling LEA generation on Atom in X86ISelDAGToDAG:: SelectLEAAddr() for all but a few pseudo-instructions 2. Identify loads and stores in a X86PassConfig::addPreEmitPass() pass and examine several preceding instructions to determine if an add, subtract, or mov can profitably be turned into an LEA. The heuristics for using LEAs efficiently must know how many cycles pass between the generation of an address and its use. This requires LEAs to be added...

...emission. That part is trivial. > > I think the real issue is that MC lowering can potentially change opcodes, so you can never really do this reliably in general :( > I’m not sure how fixable that problem is. Maybe others can provide more suggestions. You can add your pass to the end of X86PassConfig::addPreEmitPass() and it will currently be the last thing to run before the asm printer, but I don’t know if thats a guarantee or not. In theory anyone could add something after the call to preEmitPass and before this code FunctionPass *Printer = getTarget().createAsmPrinter(*this, *AsmStreame...

...g, and add the annotation pass in YourDerivedTargetPassConfig::addPreEmitPass. This will add your annotation pass very late, just before the final code is emitted. If you're using the X86 target, then the class and the function is already there: lib/Target/X86/X86TargetMachine.cpp: bool X86PassConfig::addPreEmitPass() { bool ShouldPrint = false; if (getOptLevel() != CodeGenOpt::None && getX86Subtarget().hasSSE2()) { addPass(createExecutionDependencyFixPass(&X86::VR128RegClass)); ShouldPrint = true; } if (getX86Subtarget().hasAVX() && UseVZeroUpper) {...

...g LEAs efficiently must know how many cycles pass between the address generation and its use. However, currently LEAs are inserted before this information is known (ie before register allocation). Part of the attached patch disables the current generation of LEAs. 2. Identify loads and stores in a X86PassConfig::addPreEmitPass() pass We will use an addPreEmitPass pass, similar to the VZeroUpper pass. For each load/store found we will identify its address and index, and examine previous instructions to identify where they are being generated to identify opportunities for LEAs. 3. Replacing instructions w...

...any cycles pass between the address > generation and its use. However, currently LEAs are inserted before this > information is known (ie before register allocation). Part of the attached > patch disables the current generation of LEAs. > > > > 2. Identify loads and stores in a X86PassConfig::addPreEmitPass() pass > > > > We will use an addPreEmitPass pass, similar to the VZeroUpper pass. For each > load/store found we will identify its address and index, and examine > previous instructions to identify where they are being generated to identify > opportunities for...

...that a given pass (PassID) can not be skipped. I would implement it by tracking unskippable passes in OptBisect simply filling a list during OptBisect initialization time. > Whatever piece of > code calls PassManagerBuilder methods or TargetPassConfig methods. > Possibly things like X86PassConfig have all the information for codegen > passes. This is one of the reasons I think the codegen pass pipeline > stuff is a little wonky -- it works very differently from the > higher-level pass pipeline construction. > > We should also be aware of how this will work in the presence of...

On 1/7/2013 1:53 PM, Sergei Larin wrote: > > Also, how much performance are you willing to sacrifice to do what you > do? Maybe turning off scheduling all together is an acceptable solution? Or insert the calls after scheduling. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Krzysztof, This would be ideal. How can I do the instrumentation pass after the instruction scheduling? Xu Liu Quoting Krzysztof Parzyszek <kparzysz at codeaurora.org>: > On 1/7/2013 1:53 PM, Sergei Larin wrote: >> >> Also, how much performance are you willing to sacrifice to do what you >> do? Maybe turning off scheduling all together is an acceptable solution?

On 09/28/2018 12:25 AM, Kaylor, Andrew wrote: > As I said, that’s really outside the scope of the current discussion > except to say that the relevant question is what component should make > the decision about whether or not a pass should be run. A planned way of implementation for new-pm's OptBisect is for instrumenting object to control the execution. Whenever instrumentation

Hi, I would like to execute a MachineFunctionPass after all other passes which modify the machine code. In other words, if we call llc to generate assembly file, that pass should run right before the "Assembly Printer" pass. Is there any official way to enforce this ? Best regards, Sebastien

...post. > > Then I did the following: > > 1. add "FunctionPass *createwawAnalyzer();" line to x86.h > 2. add file name to CMakelist.txt. > 3. This is going to run after postRAscheduler and before code emission so > I changed the x86TrgetMachine.cpp as follow: > void X86PassConfig::addPreEmitPass() { > /////////////add mypass here/////// > addPass(createwawAnalyzer()); > ////////////////////////////////// > if (getOptLevel() != CodeGenOpt::None) > addPass(createExecutionDependencyFixPass(&X86::VR128RegClass)); > > if (UseVZeroUpper) >...

...in YourDerivedTargetPassConfig::addPreEmitPass. This > will add your annotation pass very late, just before the final code is > emitted. If you're using the X86 target, then the class and the > function is already there: > > lib/Target/X86/X86TargetMachine.cpp: > > bool X86PassConfig::addPreEmitPass() { > bool ShouldPrint = false; > if (getOptLevel() != CodeGenOpt::None && > getX86Subtarget().hasSSE2()) { > addPass(createExecutionDependencyFixPass(&X86::VR128RegClass)); > ShouldPrint = true; > } > > if (getX86Subtarget(...

...did the following: >> >> 1. add "FunctionPass *createwawAnalyzer();" line to x86.h >> 2. add file name to CMakelist.txt. >> 3. This is going to run after postRAscheduler and before code emission so >> I changed the x86TrgetMachine.cpp as follow: >> void X86PassConfig::addPreEmitPass() { >> /////////////add mypass here/////// >> addPass(createwawAnalyzer()); >> ////////////////////////////////// >> if (getOptLevel() != CodeGenOpt::None) >> addPass(createExecutionDependencyFixPass(&X86::VR128RegClass)); >> >>...

...This is why I said earlier that the entity that understands these properties lives above passes, pass managers and OptBisect. The thing constructing the pass pipeline has all the knowledge. Whatever piece of code calls PassManagerBuilder methods or TargetPassConfig methods. Possibly things like X86PassConfig have all the information for codegen passes. This is one of the reasons I think the codegen pass pipeline stuff is a little wonky -- it works very differently from the higher-level pass pipeline construction. We should also be aware of how this will work in the presence of multiple targets (CPUs...

Thank you so much. That helped alot. Fami On Wed, Nov 4, 2015 at 9:40 AM, John Criswell <jtcriswel at gmail.com> wrote: > On 11/3/15 7:54 PM, fateme Hoseini wrote: > > Dear John, > Thank you so much for your help. I looked at those documents. Could you > kindly answer the following questions: > > Does it mean that I have to make my own backend target in order to write

...tween functions encoded with /// AVX and SSE. Index: lib/Target/X86/X86TargetMachine.cpp =================================================================== --- lib/Target/X86/X86TargetMachine.cpp (revision 196508) +++ lib/Target/X86/X86TargetMachine.cpp (working copy) @@ -197,6 +197,10 @@ bool X86PassConfig::addPostRegAlloc() { addPass(createX86FloatingPointStackifierPass()); + + if (getOptLevel() != CodeGenOpt::None) + addPass(createX86FoldRedundantInsertsPass()); + return true; // -print-machineinstr should print after this. } @@ -222,7 +226,6 @@ addPass(createX86FixupLEAs());...