similar to: [LLVMdev] Legalizing SelectionDAGs with illegal pointer type

On 27 Jun 2015, at 16:13, escha <escha at apple.com> wrote: > >> >> 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.

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

Hello all, I would like to propose a large change to LLVM that I would be happy to implement. The instruction selection legalizer knows of three different ways to legalize an action (ignoring an already legal action). - Expansion - Promotion - Custom Expanding a node will lead to one of two things - the operation will be split into several equivalent smaller operations (i.e. 64-bit

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

On Fri, 2009-01-16 at 10:03 +0100, Duncan Sands wrote: > 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.

Hi, I used 2 different compilers to compile the same IR for the same custom target. The LLVM IR code is define i32 @_Z9test_mathv() #0 { %a = alloca i32, align 4 %1 = load i32, i32* %a, align 4 ret i32 %1 } Before instruction selection, the Selection DAGs are the same: Optimized legalized selection DAG: %bb.0 '_Z9test_mathv:' SelectionDAG has 7 nodes: t0: ch = EntryToken t4:

Hey all, I am trying to implement a subtarget for the X86 architecture that only has 64 bit Registers. While running LLC on the IR for a very simple program, llc fails on an assertion that says it doesn't know how to promote ISD::FRAMEINDEX. I've tried to look for why how to promote the frameindex which is stored in a i32 variable to an i64 variable but can't seem to find where

Hi Tim, >That C++ function is probably what looks for an FrameIndex node and >has been taught that it can be folded into the load. How do you teach a function that a node can be folded into an instruction? ________________________________ From: Tim Northover <t.p.northover at gmail.com> Sent: Monday, January 21, 2019 11:52 PM To: Josh Sharp Cc: via llvm-dev Subject: Re: [llvm-dev]

On Sun, 2009-01-18 at 20:28 +0100, Duncan Sands wrote: > Hi Sanjiv, > > > + /// CustomLowerOperation - This callback is invoked for operations that are > > + /// unsupported by the target, which are registered to use 'custom' lowering, > > + /// and whose defined values are all legal. > > and whose defined values are all legal -> and whose return

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

Hi Sanjiv, > + /// CustomLowerOperation - This callback is invoked for operations that are > + /// unsupported by the target, which are registered to use 'custom' lowering, > + /// and whose defined values are all legal. and whose defined values are all legal -> and whose return values all have legal types > + /// If the target has no operations that require custom

Hello everybody, I use a target specific Intrinsic that returns an illegal type. The idea is that this returned value shall be eliminated when the Intrinsic node is lowered to a target node. I realize that this is a rather late stage, since (at least) SelectionDAGLowering::visitTargetIntrinsic() requires legal types, and type legalization in general is also done before ISelLowering. The

Is the algorithm described in the article "Near-Optimal Instruction Selection on DAGs (https://llvm.org/pubs/2008-CGO-DagISel.html)" really used in llvm instruction selection? I've studied implementation (SelectionDAGISel.cpp) and I see that instructions are selected by target specific MatcherTable generated by llvm-tblgen. In the implementation the first matching pattern from

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

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

Well, the first email is here. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081013/068667.html -----Original Message----- From: Duncan Sands [mailto:baldrick at free.fr] Sent: Thu 1/8/2009 8:41 PM To: Sanjiv Kumar Gupta - I00171 Cc: llvmdev at cs.uiuc.edu Subject: Re: PIC16 backend for llvm 2.5 Hi Sanjiv, > We are targetting a reasonably functional PIC16 backend for llvm

I never thought I’d see the day when someone proposed treating the 6502 like a GPU… —escha > On Feb 12, 2016, at 6:30 AM, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I think it would be sufficient to pick 8 or 16 pairs of zero page locations as the "registers". Who needs 128 registers, unless you're also doing inter-procedural register

Hi Christian, > I use a target specific Intrinsic that returns an illegal type. > The idea is that this returned value shall be eliminated when the > Intrinsic node is lowered to a target node. > I realize that this is a rather late stage, since (at least) > SelectionDAGLowering::visitTargetIntrinsic() requires legal types, > and type legalization in general is also done before

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.