search for: addinstselector

On Wed, 29 Nov 2006, Roman Levenstein wrote: > Thanks, this is a good idea. > > But I cannot figure out how to make a machine function pass run > _BEFORE_ the RA. I guess I'm missing something very obvious. In your target's TargetMachine::addInstSelector method, add it to the pass mgr right after your isel. > And BTW, it seems to me that currently new RA passes are not allowed > to derive from the existing ones. If it is correct, why so? Wouldn't it > be nice? I'm not sure what you mean. We don't expose linscan through a p...

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]

Hi, >> have not found any easy way to do it yet. For post-RA pass it is >> very easy and supported, but for pre-RA or post-code-selection - it >> is non obvious. > > I suggest a third approach: [snip] > 3. Write a machine function pass that runs before the RA that > translates these instructions into libcalls or other integer ops. > This would lower the f64

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

...// These 4 instructions replace the pseudo-instruction I use for LLVM's VSELECT R31 = OR srcVselectFalse, srcVselectFalse WHEREEQ R31 = OR srcVselectTrue, srcVselectTrue ENDWHERE I plan to do this as early as possible, in a pass registered in addInstSelector() normally, which gets executed immediately after the first scheduling phase. If anybody sees a problem with this, please let me know. I think it is OK to specify an empty semantics (empty DAG pattern in TableGen) for my WHEREEQ/ENDWHERE instructions delimiting the predication/conditio...

...zapnot $16,15,$1 cmpeq $1,$0,$0 beq $0,$BB1_2 #return $BB1_1: #cond_true bis $31,$31,$0 ret $31,($26),1 $BB1_2: #return lda $0,1($31) ret $31,($26),1 ---------------------------------- I have added createCFGSimplificationPass in ARMTargetMachine::addInstSelector to fix this problem. Is this the correct solution? I think that more architectures might benefit... Best Regards, Rafael

...ssInfo::createPass() const: Assertion `NormalCtor && "Cannot call createPass on PassInfo without default ctor!"' failed. A simple way to get it is to add two lines to ARMTargetMachine.cpp: #include "llvm/Transforms/Scalar.h" and PM.add(createSinkingPass()); in addInstSelector just before this line: PM.add(createARMISelDag(*this, OptLevel)); Then run anything through the ARM back end, for example: clang -cc1 -triple thumbv7-eabi -O3 -target-cpu cortex-a8 x.c -S -o x.s The interesting thing is that the assertion failure doesn't happen during the call to createSi...

Dear folks, If I want to setup a mapping between an LLVM instruction and the x86 assembly instructions it generates, is this possible? Or, an equavalent question is, when LLVM is emitting assebmly instructions, will it transform a set of LLVM instructions to a set of assembly instructions, or transform each LLVM instruction to assembly instructions independently? -- Regards, Heming Cui

On Mon, Oct 25, 2010 at 12:39 PM, Heming Cui <hc2428 at columbia.edu> wrote: > Dear folks, >     If I want to setup a mapping between an LLVM instruction and the x86 > assembly instructions it generates, is this possible? >     Or, an equavalent question is, when LLVM is emitting assebmly > instructions, will it transform a set of LLVM instructions to a set of > assembly

...led on 2006/09/04. > This causes some problems for architectures that use conditional moves > to implement select (alpha and ARM). For example, on 2006/09/03 a "if > (a) return 0; else return 1;" compiled to > I have added createCFGSimplificationPass in > ARMTargetMachine::addInstSelector to fix this problem. Is this the > correct solution? I think that more architectures might benefit... Please don't do that. Instead, please implement the TargetInstrInfo branch analysis hooks so that the branch folding pass can do this. Given info about branches, the pass already does va...

Hello. For my back end for the Connex SIMD research processor I want to implement conditional blocks (I guess the better term is predicated blocks). Predicated blocks are bordered by two instructions WHEREEQ (or WHERELT, etc) and ENDWHERE. For example, the following code executes the instructions inside the WHERE block only for the lanes where R0 == R1: EQ R0, R1;

...ote: > On Wed, 29 Nov 2006, Roman Levenstein wrote: > > Thanks, this is a good idea. > > > > But I cannot figure out how to make a machine function pass run > > _BEFORE_ the RA. I guess I'm missing something very obvious. > > In your target's TargetMachine::addInstSelector method, add it to the > pass mgr right after your isel. Thanks a lot! This is exactly what I could not understand. >> And BTW, it seems to me that currently new RA passes are not >> allowed to derive from the existing ones. If it is correct, why so? >> Wouldn't it be...

...frame lowering SE"); +} void MipsebTargetMachine::anchor() { } MipsebTargetMachine:: @@ -102,21 +155,40 @@ TargetPassConfig *MipsTargetMachine::createPassConfig(PassManagerBase &PM) { // Install an instruction selector pass using // the ISelDag to gen Mips code. bool MipsPassConfig::addInstSelector() { - addPass(createMipsISelDag(getMipsTargetMachine())); + if (getMipsSubtarget().allowMixed16_32()) { + addPass(createMipsModuleISelDag(getMipsTargetMachine())); + addPass(createMips16ISelDag(getMipsTargetMachine())); + addPass(createMipsSEISelDag(getMipsTargetMachine())); + } + else...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

...PassConfig(AMDGPUTargetMachine *TM, PassManagerBase &PM) > + : TargetPassConfig(TM, PM) {} > + > + AMDGPUTargetMachine &getAMDGPUTargetMachine() const { > + return getTM<AMDGPUTargetMachine>(); > + } > + > + virtual bool addPreISel(); > + virtual bool addInstSelector(); > + virtual bool addPreRegAlloc(); > + virtual bool addPostRegAlloc(); > + virtual bool addPreSched2(); > + virtual bool addPreEmitPass(); > +}; > +} // End of anonymous namespace > + > +TargetPassConfig *AMDGPUTargetMachine::createPassConfig(PassManagerBase &PM)...