similar to: Compare ISel

Hi llvm-dev, >> The CopyFromReg->CopyToReg->CopyFromReg sequence doesn’t have the chains set correctly: the second CopyFromReg’s input chain isn’t connected to the CopyToReg’s output chain. (This appears to be the same problem in both graphs.) The DAG mentioned was generated by the SelectionDAGBuilder and as much as possible, we only modify the files within our target so I tried

Hi, After removing support for the i64 type in the *CallingConv.td, sret-demotion is performed and we now have a store<(store 8, align 1)> DAG node being generated. Please refer to the attached dag_funcret.pdf DAG visualization. My understanding is that, the second operand(CopyFromReg->Register %1, Register %0 back-up) in the store node is the memory location allocated for the i64 type

Hi Eli, Thanks for your response. Actually, I look a lot at the ARM and THUMB1 backend implementations, and this certainly help. My architecture also have specific instructions for SP-relative accesses in a similar way than the Thumb1. During frame lowering, specific machine instructions are emitted so there’s no issue there. Also during ISelDagToDag I am able to select the right instructions.

I have a CopyToReg that is copying from different size types, what's the best way to change that to a zext or sext node based on signed or unsigned? I'm fairly unfamiliar with SelectionDAG process (outside of the docs on llvm website). It seems like I should be able to insert a custom hook using the register class to identify the type, potentially in ISelDAGToDag.cpp or is there a better

Hi All, when looking through all the existing targets, I see that each of them defines <Target>ISelLowering.{cpp,h} files. However, they define a class called "<Target>TargetLowering" (though the comments in [at least some of] those files stay the define "<Target>ISelLowering". I suspect that this class was renamed at some time (which makes sense, since I

On 7/29/2017 1:28 AM, Dr. ERDI Gergo via llvm-dev wrote: > Hi, > > During instruction selection, I have the following code for certain > LOAD instructions: > > const LoadSDNode *LD = cast<LoadSDNode>(N); > SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), > VT, PtrVT, MVT::Other, > LD->getBasePtr(), LD->getChain()); >

Thanks for getting back to me. So those nodes record if the type has already been expanded from a narrower type. Can you elaborate how I could use these to help? Again, I'm pretty unfamiliar with the SDNodes. Thanks. On Tue, Jan 27, 2015 at 3:22 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 01/27/2015 12:16 PM, Ryan Taylor wrote: > > I have a CopyToReg that

Hello. I am using the post-RA (Register Allocation) scheduler to avoid data hazards by inserting other USEFUL instructions from the program (besides NOPs) and it breaks apart some sequences of instructions which should remain "glued" together. More exactly, in my [Target]ISelDAGToDAG.cpp it is possible that I replace for example a BUILD_VECTOR with a machine SDNode called

Hello LLVM-Dev, I understand that Uses and Defs are for implicit registers. Uses is defined as for using non-operand registers and Defs is defined as for modifying non-operand registers. For example, for compare and compare with carry instructions, is my understanding correct that the instructions should be defined as described below? Considering that the carry flag is part of the status

I have a rudimentary implementation for load and store instructions, where the memory address operand is automatically post-incremented when the load or store instruction is issued. However, this is currently coded using custom lowering, and explicit pattern matching in the 'ISelDAGtoDAG' implementation. But it seems to me that I ought to be able to achieve this exclusively using

Hi All, I am new to llvm backend. I am trying out few examples to understand backend codegen. I have ported llvm LEG @ https://github.com/frasercrmck/llvm-leg to llvm 3.9 successfully. Currently, the LEG instructions are RISC load-store type instruction. I want to generate some instructions for register indirect mode, like following: IR: @a = local_unnamed_addr global i32 0, align 4 @b =

Hello Sebastien, Thank you very much for the clarification. This would greatly help us in our development. I have noticed that setOperationAction(Expand) does not always work, for these cases, does it automatically mean that setOperationAction(Custom) should be used or not necessarily? Currently, we perform a pseudo instruction instead of setting it to custom. For example in the case of a

On Dec 1, 2008, at 8:53 AM, Matthijs Kooijman wrote: > Hi All, > > when looking through all the existing targets, I see that each of > them defines > <Target>ISelLowering.{cpp,h} files. However, they define a class > called > "<Target>TargetLowering" (though the comments in [at least some of] > those > files stay the define

Are there any known examples of a backend using a function pass, not a machine function pass, to do LLVM-LLVM transformations right before ISelDagToDag? Thanks, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091005/81ec49f9/attachment.html>

Current ISelDagToDag is created once per module. The TargetLowering class is allocated there and register classes are added and the computeRegisterProperties is called. In order to switch back and forth between mips16 and mips32, I need to be able to reset what is done during computerRegisterProperties. Has anyone else looked into this for another port? Ideas? Mips16 is an instruction

Hello LLVM-Dev, Most of the processing for i64 and f64 types for our backend are emulation library calls. Some of the library calls are not defined in the RuntimeLibcalls.def Libcall enum so we have to define custom library calls. How is the ideal way of implementing the custom library calls? Providing us with a target backend having a similar functionality would also help us significantly. Say

Hi I am looking at some of the existing targets to try to understand more about writing a backend. I was a little puzzled by the use of a method ReplaceUses in *ISelDAGToDAG.cpp (*= most targets, e.g. ARM, X86..). I found its definition in the *GenDAGISel.inc file that is autogenerated from the target description. I can only assume TableGen emits this method definition for every traget.

I have a CopyToReg that is moving a 16bit reg to a 32bit reg, it's currently being mapped out as a simple mov (not an ext), I would like to change that to an ext. It seemed that the SelDAG was the easiest and cleanest way to do this. I can change the mov to an extension MI in the .td file; however, I can't tell at that point whether it's a sext or a zext, so it seemed the SelDAG was

I am trying to removing a load to a TargetGlobalAddress in ISelDagToDag that my backend does not support. The TargetGlobalAddress is assumed to always be of ConstantInt or ConstantFP type, so this transformation is valid. I am correctly able to modify the dag and remove all of the uses of the node as specified in the attached before and after dot images. The nodes in question is the

Hi All, In the target we are implementing, function return for i64 and f64 types has a different processing. For types i8 to i32, and f32, the return values are stored in their designated return registers (like how other targets does it). For i64 and f64 types, in the function call, after pushing the function parameters into the stack, the address of the allocated return memory space is