similar to: [LLVMdev] Using branches in lowered operations

See X86InstrInfo.td let usesCustomInserter = 1, isTwoAddress = 0, Defs = [EFLAGS] in def CMOV_GR8 : I<0, Pseudo, This creates a CMOV_GR8 pseudo instruction at isel time which can be expanded during scheduling time. Evan On Dec 10, 2009, at 11:46 AM, Javier Martinez wrote: > Hello, > > My expansion for an operation uses if and loops. How do I introduce > branches in the target

Hi Evan, Thanks for the useful pointer. When trying to implement the example to my situation I ran into a strange issue that I don't know how to resolve. My target doesn't support 64-bit operations and so far all operations have been expanded using LLVM except for division and remainder. For division, LLVM only gives you the option of either calling an external library or custom lowering

Chris Lattner wrote: > On Thu, 2 Dec 2004, Brent Monroe wrote: > >>I'm trying to add the xadd instruction to the X86 back end. >>xadd r/m32, r32 >>exchanges r/m32 and r32, and loads the sum into r/m32. I'm >>interested in the case where the destination operand is a >>memory location. >> >>I've added the following entry to

Thanks for spelling it out, now I understand. On Jun 5, 2011, at 6:11 AM, Galanov, Sergey wrote: > Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value. This actually looks like a

On Jun 3, 2011, at 2:59 AM, Galanov, Sergey wrote: > Hi, Bill and Jakob. > > I don't quite understand. I am talking about CMOV_GR* instructions which are conservatively marked as clobbering EFLAGS in X86InstrCompiler.td. Doesn't that mean there cannot be any use of EFLAGS in subsequent instructions before it is defined by some other instruction? > > I also don't

Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value. For an example we can look no further than the actual test which has been disabled after the fix

Hello, I have a problem with pattern matching on intrinsics. I have following code in IntrinsicsX86.td: ``` let TargetPrefix = "x86" in { // All intrinsics start with "llvm.x86.". def int_x86_mpx_bndmk: Intrinsic<[llvm_x86bnd_ty], [llvm_ptr_ty, llvm_i64_ty], []>; } ``` And following instruction that is generated when @llvm.x86.mpx.bndmk is used in code:

Can someone explain the Constraints system in X86*.td? For example: let Constraints = "$src1 = $dst" This replaces isTwoAddress (according to svn logs), which I gather is how two-address instructions used to be marked for X86. Except isTwoAddress is still used in X86InstInfo.td. So what gives? What do these two properties actually do?

Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) ... case ISD::SINT_TO_FP: case ISD::UINT_TO_FP: case ISD::EXTRACT_VECTOR_ELT: Action = TLI.getOperationAction(Node->getOpcode(), Node->getOperand(0).getValueType());

Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at

On Jun 17, 2008, at 1:36 PM, David Greene wrote: > Can someone explain the Constraints system in X86*.td? > > For example: > > let Constraints = "$src1 = $dst" > > This replaces isTwoAddress (according to svn logs), which I gather > is how > two-address instructions used to be marked for X86. You're right. This is the same as isTwoAddress, just more

On Wednesday 18 June 2008 01:30, Evan Cheng wrote: > On Jun 17, 2008, at 1:36 PM, David Greene wrote: > > Can someone explain the Constraints system in X86*.td? > > > > For example: > > > > let Constraints = "$src1 = $dst" > > > > This replaces isTwoAddress (according to svn logs), which I gather > > is how > > two-address

On Mar 19, 2010, at 12:23 PM, Villmow, Micah wrote: > Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? I don't see any. > > In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) > > ... > case ISD::SINT_TO_FP: > case ISD::UINT_TO_FP: > case ISD::EXTRACT_VECTOR_ELT: > Action =

Hi Duncan, > as well as what Eli said, ReplaceNodeResults requires (IIRC) the new node to > have the same type as the old node, which doesn't seem to be the case > here. Are you sure ? I see ReplaceNodeResults being called from functions such as CustomWidenLowerNode and CustomLowerNode. In the former, we are clearly expecting a change in type, aren't we? Even in the latter,

Hi, I see that for different targets in classes which inherits from TargetLowering there are implemented both methods: LowerOperation and ReplaceNodeResults What decides that for one given ISD we have to add handling in LowerOperation and for other in ReplaceNodeResults, when for both SetOperationAction is configured to be Custom? Is it related with number of results of given operation and

How can I custom lower the ISD::STORE? I am using -enable-legalize-types and trying to customize most of our operations in xxxTargetLowering::ReplaceNodeResults(...) There are hooks to get trunk-store and indexed-store customized, But I can't get regular STORE customized... Any suggestions? Thanks Alireza Moshtaghi Senior Software Engineer Development Systems, Microchip Technology

I have a question: In the pattern below from X86 def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), "inc{b}\tdst", [(set GR8:$dst, (add GR8:$src, 1))]>; Since we are emitting only "inc $dst", What makes sure that the $src and $dst are same register? - Sanjiv

Hi, I am defining Hexagons version of ReplaceNodeResults to change the a node of the type A: i8 = INTRINSIC_WO_CHAIN ... , ... , To B: SIGN_EXTEND (A) After returning from my function, the type legalizer calss ReplaceValuesUsesWith to replace the uses of A with B. Unfortunately, it replaces the use of A in the new node B too. So the node now is B: SIGN_EXTEND(B) , which is clearly bad and the

Hello, We have the architecture without conditional moves. Which way can we lower select? As we know there was the special pass a long time ago, but it was deleted. commit c3591a0d48ce045bbf5ae0d78a41f3dae4bb99db Author: Chris Lattner <sabre at nondot.org> Date:   Tue Feb 19 07:49:17 2008 +0000     remove the LowerSelect pass.  The last client was the old Sparc backend, which is long

> -----Original Message----- > From: Duncan Sands [mailto:baldrick at free.fr] > Sent: Friday, January 09, 2009 5:23 PM > To: Sanjiv Kumar Gupta - I00171 > Cc: llvmdev at cs.uiuc.edu > Subject: Re: PIC16 backend for llvm 2.5 > > Hi Sanjiv, > > > Well, the first email is here. > > > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon- >