similar to: [LLVMdev] Getting SELECT_CC and BR_CC DAG nodes

On Tue, Mar 15, 2016 at 2:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/15/2016 4:16 PM, Rail Shafigulin via llvm-dev wrote: > >> Below is the output of llc with a -debug-only=isel. As you could see the >> output type for load, store, and add changes from v4i32 to i32 during >> legalization. How can I preserve the output type to

I am implementing a new backend and am pretty sure I don't quite understand "the way" one is supposed to implement conditional branches. My target CPU natively supports a conditional branch instruction that accepts a condition to test (equal, less than, etc.), two operands (two registers, or one register and one immediate), and finally a target PC to branch to if the comparison

I attempt to optimize the use of the ‘CMP’ instruction on my architecture by removing the instruction instances where the Status Register already had the correct status flags. The cmp instruction in my architecture is the typical one that compares two registers, or a register with an immediate, and sets the Status Flags accordingly. I implemented my ‘cmp’ instruction in LLVM by custom lowering

Hi Eli, Thank you very much for your response. In fact, I had already tried the X86 approach before, i.e explicitly using the status register. This is the approach that appeals more to me. I left it parked because it also produced some problems (but I left it commented out). So I have now re-lived the code, and it works fine in most cases, but there’s a particular case that causes LLVM to stop

Hi Eli, Thanks again for your reply. I am unsure about implementing the getCrossCopyRegClass for my target. My target does not support or allow moves to and from the SR. The SR exists because it has implicit involvement in some instructions, but it is opaque to the assembler and to the user as a register. I mean, there are no instructions to directly move or read it, or even access it directly.

Hi, I am trying to implement support for an if-conversion pass in a backend for the ADRES CGRA architecture. >From studying the existing IfConversion pass, I observed the following: - The PredicateInstruction method is meant to insert guards into conditional instructions. - This method assumes that one will be able to get the predicate from the conditional branch instruction on which

Can someone explain how the condition code is passed from the MBlazeTargetLowering::LowerSELECT_CC to MBlazeTargetLowering::EmitCustomSelect custom inserter? In LowerSELECT_CC the condition code is never accessed (Op.GetOperand(4)) and I don't see how it ends up getting correctly passed to the MBlazeTargetLowering::EmitCustomSelect. > SDValue

Hi All, I need to implement select_cc as a "cmp; mov rX,1; brcond cnd, END; mov rX,0; END:" sequence. Chris mentioned that the PPC code (as well as the x86 SSE code) does this, but I can't seem to find it. What I really need to kmow is how to insert the branch/label pair at instruction selection phase. Anyone have an example of this?

I am trying to add support for select_cc. In ARM it can be implemented with: mov $dst, $falseVal cmp $a, $b moveq $dst, $trueVal My current strategy is to expand select_cc in two ARM nodes: ARM::SELECT and ARM::CMP. The two nodes would be connected by a flag edge. ARM::CMP would then expand to "cmp $a, $b". This instruction has no results. It only alters the CPSR (current program

someguy wrote: > Hi All, > > I need to implement select_cc as a "cmp; mov rX,1; brcond cnd, END; > mov rX,0; END:" sequence. > > Chris mentioned that the PPC code (as well as the x86 SSE code) does > this, but I can't seem to find it. > > What I really need to kmow is how to insert the branch/label pair at > instruction selection phase. > > Anyone

Note: Question is written after describing what I have coded. Hello LLVMDevs, I am trying to impliment floating point comparsion for an architecture which supports following type of floating point comparision if FPU is available: fcmp.un --> true if one of the operand is NaN fcmp.lt --> ordered less than, if any input NaN then return false fcmp.eq --> ordered equal, if any input NaN

hi Eli, thanks for reply :) i am currently decompose the BR_CC node to a target SETCC node and a target BRCOND node, but since BR_CC node sometimes is combine from a BRCOND node and SETCC node, so i just wondering if theres any better way :) regards --ether

On Oct 7, 2014, at 2:26 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Dmitry, > > On 7 October 2014 10:50, Dmitry Borisenkov <d.borisenkov at samsung.com> wrote: >> fpfail.s:26: Error: invalid instruction suffix for `ret' >> >> I downloaded Intel manual and haven’t found any mention of retl instruction, > > "retl" is the

On Fri, Dec 11, 2009 at 1:49 AM, ether zhhb <etherzhhb at gmail.com> wrote: > hi, > > i have a backend that want to do custom combine on SETCC nodes. > > but some time SETCC was combined into BR_CC before i can visit it to > do my own combine, because DAGCombiner always do its own combine > before custom combine. so, is there anyway to prevent it being > combined

Thanks to your help I've actually made some progress... Especially the SelectionDAGNodes.h was a good hint. But there are still some things that I can't figure out: // 'mov eax, 41' Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32), DAG.getConstant(41, MVT::i32), InFlag); InFlag = Chain.getValue(1); // 'inc eax' SDValue eaxVal =

hi, i have a backend that want to do custom combine on SETCC nodes. but some time SETCC was combined into BR_CC before i can visit it to do my own combine, because DAGCombiner always do its own combine before custom combine. so, is there anyway to prevent it being combined without changing the logic of DAGCombiner? thank you very much --ether

Hello everyone. I'm not an expert neither in llvm nor in x86 nor in IEEE standard for floating point numbers, thus any of my following assumptions maybe wrong. If so, I will be grateful if you clarify me what's goes wrong. But if my guesses are correct we possibly have a bug in fp arithmetics on x86. I have the following ir: @g = constant i64 1 define i32 @main() { %gval = load

On Thu, Mar 9, 2017 at 9:35 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 02/25/2017 03:06 AM, vivek pandya via llvm-dev wrote: > > Note: Question is written after describing what I have coded. > > Hello LLVMDevs, > > I am trying to impliment floating point comparsion for an architecture > which > supports following type of floating point comparision if FPU

On 03/14/2017 07:16 AM, vivek pandya wrote: > Hello Hal, > setCondCodeAction(expand) for un ordered comparison generates > semantically wrong code for me for example SETUNE gets converted to > SETOE that causes infinite loops. Can you please explain what is happening? It sounds like a bug we should fix. > > What is ideal place where I can convert unordered comparison to un

Hi all, I've spent the day trying to understand setcc/select_cc intricacies, and I thought I should mention that so far as I can tell, the modeling of CPU flags, condition codes and therefore conditional instructions seems pretty broken. On the one hand there are the SDNPInFlag/SDNPOutFlag node properties which allow you to mark an instruction as using or def-ing the CPU flags