search for: replacenoderesult

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 gmail.com> napisał: > ReplaceNodeRes...

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,...

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 LowerOperation is called when there is only one SDValue?...

Hi Pranav, >> 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 cle...

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: SI...

...t needs special "alignment" of its gpr pointer when the argument is i64. Ie. I need to know if I am lowering va_arg of i64. I tried to tackle this by providing custom lowering for va_arg(i64) that just aligns stuff properly. I do this by adding ISD::VA_ARG handling to PPCTargetLowering::ReplaceNodeResults() where I need to read/increse/write a number in memory while providing nothing in &Results. The problem is that the Chain of the va_arg node needs to be updated but I dont know how to do that. I tried stuff like: SDValue Ops[] = { InChain, VAListPtr, N->getOperand(2), N->getO...

...gt; 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- > 20081013/068667.html > > thanks, I remember now (more or less). So would something like > ReplaceNodeResults > solve the problem? > Well the magnitude of the task is not small. ExpandIntegerOperand() calls LowerOperation() to allow targets to handle illegal operands. So we will need to change the interface of LowerOperation() to pass an extra argument called Results, which is an array of SDValue....

On Fri, Aug 31, 2012 at 2:48 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > 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 The type legalizer asked your target to replace an node with an illegal type with a node with a legal type, and you...

...will need to change the interface of > LowerOperation() to pass an extra argument called Results, which is an > array of SDValue. Targets will push the result values in this array and > then we can replace values in ExpandIntegerOperand(). Very much like > what CustomLowerResults() and ReplaceNodeResults() are doing currently. > > The problem is that do we want to change calls to LowerOperation() in > LegalizeDAG as well? I think probably that is the right approach to go > in the longer term. But currently I suggest that "Results" be the last > argument to LowerOperation(...

...the interface of > > LowerOperation() to pass an extra argument called Results, which is an > > array of SDValue. Targets will push the result values in this array and > > then we can replace values in ExpandIntegerOperand(). Very much like > > what CustomLowerResults() and ReplaceNodeResults() are doing currently. > > > > The problem is that do we want to change calls to LowerOperation() in > > LegalizeDAG as well? I think probably that is the right approach to go > > in the longer term. But currently I suggest that "Results" be the last > > ar...

...the same discussion in the above thread still holds good and whether we can start working on it as described therein. I don't remember what the discussion was about any more. The link doesn't contain much. Anyway, as you may have noticed I changed the definition of the target hook "ReplaceNodeResults". Probably the same method, or one with a similar definition, should be used for custom lowering in the case of an illegal operand. Would this solve your problem? Ciao, Duncan. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piper...

Hi Sanjiv, > Well, the first email is here. > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081013/068667.html thanks, I remember now (more or less). So would something like ReplaceNodeResults solve the problem? Ciao, Duncan.

...l 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 the division. If the operation is custom lowered, because the return type (i64) is not legal, LLVM ends up calling into ReplaceNodeResults(). ReplaceNodeResults() has the restriction that the result has to have the same number of values and types. This forces the lowering function to return a target defined custom i64 node. At the next legalization cycle ExpandIntegerResults() is called to expand this node causing an assert because g...

...hod is for use when > an operand has an illegal type, right? Yet the comment makes no mention of this. > There's also of no mention of the fact that you are allowed to not place anything > in Results, and what that means. > Taken care of. > Also, is there any reason not to use ReplaceNodeResults rather than introducing > a new method for type legalization? > ReplaceNodeResults and LowerOperation have been used for different purposes by different targets, and have been implemented differently. The former is meant to legalize illegal value types and the latter is meant to legalize op...

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 really know is the 32-bit multiply. Then you'd have to take care of that node elsewhere, of course. Cheers....

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

...e name seem too generic for me. This method is for use when an operand has an illegal type, right? Yet the comment makes no mention of this. There's also of no mention of the fact that you are allowed to not place anything in Results, and what that means. Also, is there any reason not to use ReplaceNodeResults rather than introducing a new method for type legalization? > + case ISD::ANY_EXTEND: > + Results.push_back(PromoteIntOp_ANY_EXTEND(N)); break; This is wrong if PromoteIntOp_ANY_EXTEND returned a value with no node. Likewise for all the others. Better I think to simply handle...

Hi, I recently started helping with the LLVM AVR backend [1]. The AVR is an 8 bit core with pointer type i16. That makes pointers illegal in the SelectionDAG. As far as I understand it, it is the backends job to legalize these nodes by using the ReplaceNodeResults/LowerOperation callbacks. Is that about right? I have the feeling that the symbolic nodes carrying pointers, like FrameIndex are special and I have no idea how to properly legalize them. Is that even possible? Is it possible without modifying core LLVM? If it requires modifying core would that be...

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

...patch. However, Hexagon gives me headaches. I tried to limit the scope of the patch to the BeforeLegalizeTypes phase and Hexagon still reaches the unreachable. Hexagon tries to split or widen a vector type for a node with custom lowering where the unreachable arises from inside TargetLowering::ReplaceNodeResults which is not overwritten in the Hexagon backend. To avoid generating illegal code after all I queried TLI if all generated operations are legal operations for the given vector type. if ( TLI.isOperationLegal(ISD::SUB, VT) && TLI.isOperationLegal(ISD::ADD, VT) &&a...