search for: istermin

...|(1ULL<<MCID::MayLoad)|(1ULL<<MCID::Predicable)|(1ULL<<MCID::Terminator)|(1ULL<<MCID::Variadic)|(1ULL<<MCID::UnmodeledSideEffects)|(1ULL<<MCID::ExtraDefRegAllocReq), 0x0ULL, nullptr, nullptr, OperandInfo52, -1 ,nullptr }, // Inst #2399 = t2LDMIA_RET The test isTerminator only checks the MCInstrDesc: /// Various passes use this to insert code into the bottom of a basic block, /// but before control flow occurs. bool isTerminator() const { return Flags & (1 << MCID::Terminator); } -Krzysztof ----- Renato: On 11 August 2015 at 14:54, Krz...

...gr2 = gr4; > * gr5 = gr1; > * gr6 = gr4; > * gr1 = gr1; > goto LBB8; > > I'm guessing that those copies are inserted by the register allocator, and > in particular, that is probably where gr6 is supposed to get it's value. > If you set the isTerminator flag on your 'if <>0 goto LBB11;' things will > probably magically start working for you, as the copies will be inserted > BEFORE the branch instead of after it. Hmm.. this is what I have in td file already: let isTerminator = 1 in def GOTO : Unknown<"goto&quot...

On Wed, 23 Jun 2004, Vladimir Prus wrote: > Hmm.. this is what I have in td file already: > > let isTerminator = 1 in > def GOTO : Unknown<"goto">; > def IFEQ : Unknown<"if =0 goto">; > def IFNEQ : Unknown<"if <>0 goto">; > ..... > > Should this work? Nope, but try this: let isTerminator = 1 in { def GOTO : Un...

Hello, The function ARMBaseInstrInfo::AnalyzeBranch contains the following piece of code: } else if (I->isReturn()) { // Returns can't be analyzed, but we should run cleanup. CantAnalyze = !isPredicated(I); } else { This could lead to cases where for a block that ends with a conditional return, AnalyzeBranch returns false (i.e. analyzed), both TBB and FBB are

...hich includes region formation for general VLIW packetization/bundling. As such we need to handle pretty much all instructions and any terminators, including labels (though I know it sounds strange). Nevertheless, ScheduleDAGInstrs::buildSchedGraph still has this hard assert in it: assert((!MI->isTerminator() || CanHandleTerminators) && !MI->isLabel() && "Cannot schedule terminators or labels!"); ...and we have been OK till now by simply disabling it in our local version of the code, but since we are now working towards upstreaming all our code, this could...

...ation for general VLIW packetization/bundling. As such we need to handle > pretty much all instructions and any terminators, including labels (though I > know it sounds strange). Nevertheless, ScheduleDAGInstrs::buildSchedGraph > still has this hard assert in it: > > assert((!MI->isTerminator() || CanHandleTerminators) && !MI->isLabel() && > "Cannot schedule terminators or labels!"); > > ...and we have been OK till now by simply disabling it in our local version > of the code, but since we are now working towards upstreaming all ou...

...mething like: inline void __isb() { __schedule_barrier_full(); __builtin_arm_isb(); __schedule_barrier_full(); } To implement these intrinsics, I think the best method is to add target-independent pseudo-instructions with appropriate properties(hasSideEffects for memory barrier and isTerminator for full barrier) and a pseudo-instruction elimination pass after the scheduling pass. What do people think of this idea? Cheers, Yi ------ [1] A piece of code that requires such behaviour is: Data_array[n] = x; // memory access __DSB(); __WFI(); // This cannot get execute...

On Feb 8, 2013, at 12:28 PM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > On 02/08/2013 08:20 PM, Tobias Grosser wrote: >> That sounds elegant and seems to solve the correctness problems. > > There is no big difference here except that the memory instructions > would not need the metadata. > > I do not think the abundance of metadata is really the

Replying to my self here. It seems I was missing an isTerminator = 1 on the branch instruction in question, so LLVM didn't know that the instruction terminated a basic block. Does that make sense, or is just masking some other problem? Thanks, Andreas On 9/28/07, Andreas Fredriksson <deplinenoise at gmail.com> wrote: > Hi, > I'm trying...

...if <>0 goto LBB11; * gr2 = gr4; * gr5 = gr1; * gr6 = gr4; * gr1 = gr1; goto LBB8; I'm guessing that those copies are inserted by the register allocator, and in particular, that is probably where gr6 is supposed to get it's value. If you set the isTerminator flag on your 'if <>0 goto LBB11;' things will probably magically start working for you, as the copies will be inserted BEFORE the branch instead of after it. Also, if you haven't already, you might want to teach TargetInstrInfo that '=' is a move instruction (implemen...

I'm analyzing the basic blocks of MachineInstructions that LLVM generates for my TargetMachine to try to reconstruct high-level flow control. I misunderstood the isTerminator property of an instruction to mean that it had to be at the end of a basic block, but now I've seen blocks that end with a conditional branch followed by an unconditional branch. I'm sure this depends somewhat on my target, but can there be an arbitrary number of conditional br...

...sentence i tried to express the question whether there is a way to persuade the code generator to use another register to load (or move) the function pointer to (right before the callee saved register restore) but thinking a little further that's nonsense. something like let isCall = 1, isTerminator = 1, isReturn = 1, isBarrier = 1, noResults = 1, ifDestRegisterisCalleeSavedEmitAMoveToECXAndJumpToThat=1 in def TAILJMPr : I<0xFF, MRM4r, (ops GR32:$dst), "jmp {*}$dst # TAIL CALL jmpr", []>; On 8 Aug 2007, at 18:27, Dale Johannesen wrote: > In...

Hello, Arnold. > Is there a way to indicate that the register the tail call > instruction uses as destination needs to be valid after the callee > saved registers have been restored? (some X86InstrInfo.td foo magic > maybe ?) It's wrong way to do the things. Because in this case you either violate the ABI for callee, or you're restricted to do tail call lowering only for

...amp;ValueMap, const char *NameSuffix, Function *F) { BasicBlock *NewBB = new BasicBlock("", F); if (BB->hasName()) NewBB->setName(BB->getName()+NameSuffix); bool hasCalls = false, hasDynamicAllocas = false, hasStaticAllocas = false, isTerminal =false; // Loop over all instructions, and copy them over. for (BasicBlock::const_iterator II = BB->begin(), IE = BB->end(); II != IE; ++II) { const Instruction *NwInst = cast<Instruction>((II)); Instruction *NewInst...

On Thu, Mar 29, 2012 at 01:50:58PM -0500, Sergei Larin wrote: > Tom, > > What is in your isSchedulingBoundary? If it contains isLabel you might > need to disable that assert: > > assert(!MI->isTerminator() && !MI->isLabel() && > "Cannot schedule terminators or labels!"); > > Sergei Larin > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > > I haven't implemented it, so it's still the default i...

Tom, What is in your isSchedulingBoundary? If it contains isLabel you might need to disable that assert: assert(!MI->isTerminator() && !MI->isLabel() && "Cannot schedule terminators or labels!"); Sergei Larin -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: Tom Stellard [mailto:thomas.stellard at amd.com] > Sent:...

...store %ar6, %gr1 > %ar6 = - %ar6, 2 > > The code after "goto" is disturbing. It looks like spill code, but it's not > going to be ever executed. Any ideas why it's generated? Is there any > additional information I should provide? Yup, just add the "isTerminator" bit on your gotos in your tablegen description for the instruction. This informs the code generator that any spill code has to go above the instructions. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/

...const char *NameSuffix, Function *F) { > > BasicBlock *NewBB = new BasicBlock("", F); > if (BB->hasName()) NewBB->setName(BB->getName()+NameSuffix); > > bool hasCalls = false, hasDynamicAllocas = false, > hasStaticAllocas = false, isTerminal =false; > > // Loop over all instructions, and copy them over. > for (BasicBlock::const_iterator II = BB->begin(), IE = BB->end(); > II != IE; ++II) > { > const Instruction *NwInst = cast<Instruction>((II)); What...

Hi, I'm trying to write up my little m68k backend things have been going smoothly. I've been working with the x86 backend as a template, fixing things as I go. Now I've run into branches and I have a crash I don't really understand. Here's the sample IR I'm running llc on to generate assembly: define i32 @ilog2(i32 %x) { entry: %tmp718 = icmp eq i32 %x, 0

On Oct 15, 2008, at 11:38 AMPDT, Daniel M Gessel wrote: > I'm analyzing the basic blocks of MachineInstructions that LLVM > generates for my TargetMachine to try to reconstruct high-level flow > control. > > I misunderstood the isTerminator property of an instruction to mean > that it had to be at the end of a basic block, but now I've seen > blocks that end with a conditional branch followed by an unconditional > branch. > > I'm sure this depends somewhat on my target, but can there be an > arbitrary num...