search for: xxxtargetlowering

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

To generate code for a target which doesn't have immediate constant as instruction operand, do I (the target specific back-end, XXXTarget) need to provide code to break up the SDNode with constant (like ISD::ADD $reg1, #1) to 2 SDNodes (ISD::LOAD $reg2, #1; ISD::ADD $reg1, $reg2) in my XXXTargetLowering::LowerOperation, or LLVM target-independent framework can do such transformation automatically with my instruction pattern definition? Thanks -Thomson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141224/f...

...liminate a lot of messy coding takes place in target lowering and DAG to DAG. The average person doing porting should not, IMO, be exposed to many of the details of chains, glue and other complexities and idiosyncrasies of the Selection DAG. The main idea is to eliminate or shrink considerably XXXTargetLowering and XXXISelDagToDag. There could also be some Machine IR added to the current IR that is not target specific. My 2c. Reed

Hi, I am planning to expanding the pseudo instructions in XXXTargetLowering::EmitInstrWithCustomInserter(), and use temporary virtual registers as operands. If I use virtual registers, do I need to mark them as "early clobber"? I saw that sometimes they marked virtual register as "early clobber" in EmitInstrWithCustomInserter() in MIPS backend. What is...

Currently, Alpha, PowerPC and X86 implement LowerFORMAL_ARGUMENTS. PowerPC and X86 lower ISD::CALL in LowerOperation. Alpha implements custom select. What is the preferred way to implement this? Thanks, Rafael

Hi Dan, If you set the node's action to "Custom", you should be able to interfere in the type legalisation phase (before it gets promoted to a 64-bit MUL) by overriding the "ReplaceNodeResults" function. You could either expand it to a different libcall directly there, or replace it with a target-specific node (say XXXISD::MUL32) which claims to take i64 types but you

...SD::MUL32 in the LowerOperation, then after it is created doing the custom change of MUL, that it just dies not knowing how to lower the machine op. I would have thought that there was a default path for any XXXISD operation? And I didn't see other Targets generating their machine ops SDValue XXXTargetLowering:: LowerOperation(SDValue Op, SelectionDAG &DAG) const { case XXXISD::MUL32: return SDValue(); Really appreciate your help and any other pointers. Dan On Wed, Jul 31, 2013 at 12:38 AM, Tim Northover <t.p.northover at gmail.com>wrote: > Hi Dan, > > If you set the node...

Thanks for the information, allow maybe I can re-phrase the question or issue. Assume 64-bit register types, but integer is 32-bit. Already have table generation of the 64-bit operation descriptions. How about this modified approach? Before type-legalization, I'd really like to move all MUL I64 to a subroutine call of my own choice. This would be a form of customization, but I want this

Hi, there I am writing an backend, and I met a problem. We don't have load/store instructions for vector predicate registers(vpr for short). The hardware has 64 vector registers(vr for short) and 8 vector predicate registers. And there is no move instructions between vr and vpr. vr supports many operations, and vpr supports vpror, vprxor, vprand and vprinv operations. A vr has 512 bits, and