search for: dagtodagisel

I am currently working on DAGToDAGISel class for MIPS and am trying to figure out a way to use INTRINSIC_W_CHAIN for an intrinsic which can return a value. My intrinsic is defined as: Intrinsic<[llvm_i32_ty],[llvm_i32_ty,llvm_i32_ty,llvm_i32_ty,llvm_i32_ty],[IntrReadWriteArgMem]>; i.e. it has four arguments and one return value...

What I am thinking of now is to just register the MIPS116 and MIPS32 DAGToDAGISel passes and then within run on machine function, I can just return if the current mode indicates that mips16 is needed for example, so the run on machine function for Mips32 would return immediately. On 03/27/2013 10:05 AM, Reed Kotler wrote: > I guess another way to do this is to just register...

I'm implementing this ability to switch between mips16 and mips32 on a per function basis. One issue that I've run into is regarding the DAGToDAGIsel pass. We have a different subclass for mips16 and non mips16 ( conceivably later there could be a separate one for micromips). I need to run a different pass depending on whether it's mips16 or mips32. My initial plan was to create a dummy ModuleDAGToDAGIsel whose sole purpose in it's...

...least passes in this case. So in principle turn on the dual mode now and debug whatever misc is left. For this I insert another pass before the mips16 and non mips16 passes. On 03/27/2013 10:19 AM, Reed Kotler wrote: > What I am thinking of now is to just register the MIPS116 and MIPS32 > DAGToDAGISel passes and then within run on machine function, I can just > return if the current mode indicates that mips16 is needed for example, > so the run on machine function for Mips32 would return immediately. > > On 03/27/2013 10:05 AM, Reed Kotler wrote: >> I guess another way to do th...

...t think that the TargetLowering classes have anything to do with instruction selection [any more?]). However, the inconsistent filenames are a bit confusing. Perhaps somebody should rename the lot of them? The same goes for <Target>ISelDAGToDAG.cpp, which defines a class called <Target>DAGToDAGISel. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081201/241b3ef7/attachment.sig>

...s for mips16 and mips32 and have them return immediately if it is not their turn to run. On 03/27/2013 08:58 AM, Reed Kotler wrote: > I'm implementing this ability to switch between mips16 and mips32 on a > per function basis. > > One issue that I've run into is regarding the DAGToDAGIsel pass. > > We have a different subclass for mips16 and non mips16 ( conceivably > later there could be a separate one for micromips). > > > I need to run a different pass depending on whether it's mips16 or mips32. > > My initial plan was to create a dummy ModuleDAGToDAGI...

...t; So in principle turn on the dual mode now and debug whatever misc is left. > > For this I insert another pass before the mips16 and non mips16 passes. > > On 03/27/2013 10:19 AM, Reed Kotler wrote: >> What I am thinking of now is to just register the MIPS116 and MIPS32 >> DAGToDAGISel passes and then within run on machine function, I can just >> return if the current mode indicates that mips16 is needed for example, >> so the run on machine function for Mips32 would return immediately. >> >> On 03/27/2013 10:05 AM, Reed Kotler wrote: >>> I guess...

TLDR: Heads up for out of tree backends - you're going to need to update your *DAGToDAGISel::Select method to unconditionally replace nodes directly instead of returning the desired replacement. So I'm working on fixing the undefined behaviour I described in llvm.org/PR26808. As part of this, we need to stop looking into deleted SDNodes to check if they were, in fact, deleted. A big...

...VM IR Instructions to generated SDNodes: public: // Alex: added a getter for NodeMap DenseMap<const Value*, SDValue> &getNodeMap() { return NodeMap; } A small problem is that it seems that when I access the NodeMap in [Target]DAGToDAGISel::Select(SDNode *Node) method (part of subclass of SelectionDAGISel), the NodeMap contains quite a few SDNodes tagged as <<Deleted Node!>> (for the nodes that were already selected). But the current SDNode, given as parameter to Select() is valid and we can search for it in NodeM...

...r, the inconsistent > filenames are a > bit confusing. Perhaps somebody should rename the lot of them? Sure, I'd support renaming them to <target>TargetLowering.cpp etc. > The same goes for <Target>ISelDAGToDAG.cpp, which defines a class > called > <Target>DAGToDAGISel. The DAGToDAG suffix is actually a pretty old historical artifact at this point. It would be better to rename the classes and files to <target>DAGISel. -Chris

Update: All in tree backends now implement `void Select`. I'll be removing the SelectImpl path on Monday. Justin Bogner <mail at justinbogner.com> writes: > TLDR: Heads up for out of tree backends - you're going to need to update > your *DAGToDAGISel::Select method to unconditionally replace nodes > directly instead of returning the desired replacement. > > So I'm working on fixing the undefined behaviour I described in > llvm.org/PR26808. As part of this, we need to stop looking into deleted > SDNodes to check if they were,...

...rg> wrote: > Update: All in tree backends now implement `void Select`. I'll be > removing the SelectImpl path on Monday. > > Justin Bogner <mail at justinbogner.com> writes: >> TLDR: Heads up for out of tree backends - you're going to need to update >> your *DAGToDAGISel::Select method to unconditionally replace nodes >> directly instead of returning the desired replacement. >> >> So I'm working on fixing the undefined behaviour I described in >> llvm.org/PR26808. As part of this, we need to stop looking into deleted >> SDNodes to...

No objections from me to make it run later. I didn't see the potential conflicts when I added that code. Delayed combine, custom lowering, or DAGToDAGISel all seem like viable options to me. On Mon, Aug 26, 2019 at 2:04 PM Roman Lebedev <lebedev.ri at gmail.com> wrote: > I have previously posted these two patches: > > [X86][CodeGen][NFC] Delay `combineIncDecVector()` from DAGCombine to > X86DAGToDAGISel > https://reviews.llvm.o...

...object relating LLVM IR Instructions to generated SDNodes: >> public: // Alex: added a getter for NodeMap DenseMap<const Value*, SDValue> >> &getNodeMap() { return NodeMap; } >> >> A small problem is that it seems that when I access the NodeMap in >> [Target]DAGToDAGISel::Select(SDNode *Node) method (part of subclass of >> SelectionDAGISel), the NodeMap contains quite a few SDNodes tagged as <<Deleted >> Node!>> (for the nodes that were already selected). But the current SDNode, given as >> parameter to Select() is valid and we can sea...

Hi Quentin, yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer". I do have a very simple DAGToDAGISel::Select() method: SDNode *MyTargetDAGToDAGISel::Select(SDNode *N) { SDLoc dl(N); // default implementation if (N -> isMachineOpcode()) { N -> setNodeId(-1); return NULL; // Already selected. } SDNode *res = SelectCode(N); return res; } Is that too simple? There are no...

...t; Hi Boris, > > On Oct 29, 2014, at 10:35 AM, Boris Boesler <baembel at gmx.de> wrote: > >> Hi Quentin, >> >> yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer". >> I do have a very simple DAGToDAGISel::Select() method: >> >> SDNode *MyTargetDAGToDAGISel::Select(SDNode *N) >> { >> SDLoc dl(N); >> // default implementation >> if (N -> isMachineOpcode()) { >> N -> setNodeId(-1); >> return NULL; // Already selected. >> } >> SDN...

...backends now implement `void Select`. I'll be >> removing the SelectImpl path on Monday. This is done in r270454. >> Justin Bogner <mail at justinbogner.com> writes: >>> TLDR: Heads up for out of tree backends - you're going to need to update >>> your *DAGToDAGISel::Select method to unconditionally replace nodes >>> directly instead of returning the desired replacement. >>> >>> So I'm working on fixing the undefined behaviour I described in >>> llvm.org/PR26808. As part of this, we need to stop looking into deleted >...

I think DAGToDAG is too late because the build_vector has already been turned into a constant pool load by then so it’s a little difficult to get back. Maybe we can delay it to !DCI.isBeforeLegalizeOps()? That would at least let the first DAG combine and the post type legalization DAG combine see the add, 1. +Sanjay as well From: Amaury Séchet <deadalnix at gmail.com> Sent: Monday, August

...at 10:35 AM, Boris Boesler <baembel at gmx.de> wrote: >>> >>>> Hi Quentin, >>>> >>>> yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer". >>>> I do have a very simple DAGToDAGISel::Select() method: >>>> >>>> SDNode *MyTargetDAGToDAGISel::Select(SDNode *N) >>>> { >>>> SDLoc dl(N); >>>> // default implementation >>>> if (N -> isMachineOpcode()) { >>>> N -> setNodeId(-1); >>>>...

...machine code the immediate is a relative offset for the PC). I have spent some time looking at the PPC and SPARC backends, but obviously these are much more complicated than what I require to implement. Consequently, I am not correctly grasping the interactions between ARCHInstrInfo.td and ARCHDAGToDAGISel.cpp I did manage to hack something together based on a copy of SPARC (with a SABRE namespace etc) but the instruction selection was incorrect and I obtained a "Cannot yet select:0x..." assertion failure from SABREDAGToDAGIsel::SelectCode when I attempted a llc -march sabre helloworld....