similar to: Handling node through TargetLowering::LowerOperation vs TargetLowering::ReplaceNodeResults

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

Hi, I'm a litle bit puzzled by the TargetLowering::LowerOperation function, and what different callers of this function assumes about the returned value. In several places it seems like it is assumed that LowerOperation can return three kinds of values: * Something completely new. * SDValue() * The same SDValue as LowerOperation was called on. However in some places, e.g. in

Hi, On 01/22/2016 05:02 PM, Tom Stellard wrote: > On Fri, Jan 22, 2016 at 01:58:49PM +0100, Mikael Holmén via llvm-dev wrote: >> Hi, >> >> I'm a litle bit puzzled by the TargetLowering::LowerOperation function, >> and what different callers of this function assumes about the returned >> value. >> > SelectionDAGLegalize::LegalizeOp() is your best

Hi, for DAG-to-DAG instruction selection I’ve implemented a pattern, which creates from one SDNode two instructions, something like: def: Pat<(NEW_SDNODE REG:$r1), (INST_OUT (INST_IN), REG:$r1)>; where INST_IN doesn't accepts any inputs and INST_OUT accepts two inputs - one returned by INST_IN and REG;$r1. Is there any possibility to ‘Glue’ two instruction created

You could hardcode a register for the pseudo instruction to use in the td file. The register allocator will make sure not to clobber it. let uses = [ R1 ], defs = [ R1 ] in { def MYINST : Pseudo<> } On Wed, Dec 11, 2019 at 10:25 AM Przemyslaw Ossowski via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I have one more question regarding expanding pseudo instruction. > >

On Wed, May 1, 2019 at 2:48 PM Przemyslaw Ossowski < przemyslaw.ossowski at googlemail.com> wrote: > Thanks Mehdi for the suggestion. > I want to customize handling of 'load' instruction during processing DAG, > but on IR level I want the 'load' to be treated in different passes as > common load. So I'm afraid that replacing 'load' with Intrinsic

On Tue, Apr 30, 2019 at 3:51 PM Przemyslaw Ossowski via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > as I wrote in mu previous post I wanted to somehow mark one IR instruction > (in this particular case it would be 'load') during dedicated pass, which > will set the marking based on neighboring instructions. Next I wanted to > somehow to convey this marking

Hello, I’m looking for the best approach which would allow for marking given LLVM IR instruction during IR custom pass and later utilizing that information during DAG Instruction Selection in order to match given pattern based on this marking. I’m wondering if marking IR instruction utilizing Metadata is good idea. But how later pass that information to DAG and appropriately mark in

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, aren't we? Even in the latter,

Hi all, my question is maybe not directly related with LLVM but general with compilers. The common approach is that compilers often don't align stack pointer for leaf functions if the function utilizes stack just for keeping variables of small sizes. I’m wondering what is the benefit of such behavior. Is saving a few bytes of the stack just once worth of such approach? Or maybe

Hi Eli, I would like to clarify generally what the difference is between returning SDValue() and Op (input argument unchanged) from LowerOperation()? My understanding is that returning SDValue() means that Target gives up, and the common code is supposed to handle it. Returning Op, the unchanged argument, means that the Target is happy with the node as it is, and the common code can move on

> On Jan 23, 2017, at 12:36, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/23/2017 5:21 AM, Jonas Paulsson wrote: >> Hi Eli, >> >> I would like to clarify generally what the difference is between returning SDValue() and Op (input argument unchanged) from LowerOperation()? >> >> My understanding is that returning SDValue()

Hi! I am trying to implement va_arg() on ppc32. Everything went smooth, except implementing va_arg() of 64bit int. Since i64 is not a legal type on ppc32 DAGTypeLegalizer::ExpandRes_VAARG() splits the va_arg(i64) into two i32 va_args. The problem with ppc32 va_arg is that it needs special "alignment" of its gpr pointer when the argument is i64. Ie. I need to know if I am lowering

> -----Original Message----- > From: Duncan Sands [mailto:baldrick at free.fr] > Sent: Friday, January 09, 2009 5:23 PM > To: Sanjiv Kumar Gupta - I00171 > Cc: llvmdev at cs.uiuc.edu > 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- >

Salut Ivan, On Fri, Jun 1, 2012 at 7:22 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Sebastian, > > Le 25/05/2012 18:54, Sebastian Pop a écrit : >> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org>  wrote: >>> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov>  wrote: >>>> Sebastian,

On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop <spop at codeaurora.org> wrote: > On Thu, May 24, 2012 at 5:06 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> Sebastian, >> >> First, it might be useful to look at what is done in the PowerPC >> backend. PPC also has condition registers that are larger than the >> 1-bit conditional results, and it defines

Hi Sanjiv, > 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. Targets will push the result values in this array and > then we can replace values in

Hi Sebastian, Le 25/05/2012 18:54, Sebastian Pop a écrit : > On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org> wrote: >> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov> wrote: >>> Sebastian, >>> >>> First, it might be useful to look at what is done in the PowerPC >>> backend. PPC also has condition

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 clearly expecting a change in type,

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