search for: dagtodagisel

Displaying 20 results from an estimated 22 matches for "dagtodagisel".

2015 Mar 09
2
[LLVMdev] LLVM Backend DAGToDAGISel INTRINSIC
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...
2013 Mar 27
2
[LLVMdev] LLVM pass question
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...
2013 Mar 27
2
[LLVMdev] LLVM pass question
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...
2013 Mar 27
0
[LLVMdev] LLVM pass question
...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...
2008 Dec 01
2
[LLVMdev] TargetISelLowering
...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>
2013 Mar 27
0
[LLVMdev] LLVM pass question
...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...
2013 Mar 27
1
[LLVMdev] LLVM pass question
...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...
2016 May 05
2
SelectionDAGISel::Select's API considered harmful
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...
2016 Oct 21
2
Accessing the associated LLVM IR Instruction for an SDNode used in instruction selection (back end)
...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...
2008 Dec 01
0
[LLVMdev] TargetISelLowering
...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
2016 May 21
0
SelectionDAGISel::Select's API considered harmful
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,...
2016 May 23
2
SelectionDAGISel::Select's API considered harmful
...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...
2019 Aug 26
2
LLVM X86 backend combineIncDecVector's transform
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...
2016 Oct 24
2
Accessing the associated LLVM IR Instruction for an SDNode used in instruction selection (back end)
...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...
2014 Oct 29
2
[LLVMdev] Virtual register def doesn't dominate all uses
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...
2014 Oct 31
2
[LLVMdev] Virtual register def doesn't dominate all uses
...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...
2016 May 23
0
SelectionDAGISel::Select's API considered harmful
...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 >...
2019 Aug 26
1
LLVM X86 backend combineIncDecVector's transform
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
2014 Nov 01
2
[LLVMdev] Virtual register def doesn't dominate all uses
...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); >>>>...
2007 Mar 22
1
[LLVMdev] Backend: 2 address + 17bit immediate
...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....