similar to: [LLVMdev] custom lowering with multiple results

Here's a concrete example of what I'm having problems with: trying to use LowerOperation to replace one node with two nodes. Imagine I have a new instruction "read_world" that sets the status flags according to some kind of global state. In order to generate this instruction I have a built-in function with the prototype "int __builtin_read_world(void)". I also have a

Hi, When expanding multiply operation in LegalizeTypes LLVM generates some nodes such as UMUL_LOHI (please refer file LegalizeIntegerTypes.cpp - function - ExpandIntegerResult). However while lowering this operation in LegalizeDAG (please refer file LegalizeDAG.cpp - function - LegalizeOp) the comment says "These nodes will only be produced by target-specific lowering.....".

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 Akira, On 01/06/12 02:27, Hatanaka, Akira wrote: > In LegalizeDAG.cpp, truncating stores are custom-lowered in line 1314-1317: > > 1314 case TargetLowering::Custom: > 1315 ReplaceNode(SDValue(Node, 0), > 1316 TLI.LowerOperation(SDValue(Node, 0), DAG)); > 1317 break; > > Is there a reason it doesn't check whether the

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

In LegalizeDAG.cpp, truncating stores are custom-lowered in line 1314-1317: 1314 case TargetLowering::Custom: 1315 ReplaceNode(SDValue(Node, 0), 1316 TLI.LowerOperation(SDValue(Node, 0), DAG)); 1317 break; Is there a reason it doesn't check whether the SDValue returned from TargetLowering::LowerOperation is null before it replaces the

There have been some useful replies to my question. In particular, Eli Friedman explained that my change to LegalizeDAG.cpp was wrong and suggested that I use a MERGE_VALUES node in ARMISelLowering.cpp. Unfortunately, that hasn't solved the problem I was having. I still get the same old assertion failure: "#operands for dag node doesn't match .td file!" However, here's an

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

Thanks, for insight, Eli, So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one should probably do setOperationAction(ISD::STORE, MVT::i1, Custom); and implement it in NVPTXTargetLowering::LowerOperation. But this issue makes a good point about the code efficiency: I suspect such expansion will be very ugly in terms of performance. Probably we can do much better if bool would use

In our (NVIDIA's) NVVM IR spec, we define i1 having a memory size of 8 bit. setOperationAction(ISD::LOAD, MVT::i1, Custom); setOperationAction(ISD::STORE, MVT::i1, Custom); is the right way to go. Yuan From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Justin Holewinski Sent: Monday, July 02, 2012 9:55 AM To: Dmitry N. Mikushin Cc: llvmdev at

OK, thanks. For our project I implemented a similar workaround: extend each i1 memory item to i8 and load/store i1 to i8 with a type cast. Still, the issue in NVPTX remains. I don't know whether NVIDIA or community fellows have any reasonable priority to fix it (or at least put an NYI assertion!). It seems to be quite more complex, than implementing custom lowering handler, that's why

Hi Duncan, > did you declare i1 to be an illegal type? No. How? 2012/6/30 Duncan Sands <baldrick at free.fr>: > Hi Dmitry, >> So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one >> should probably do setOperationAction(ISD::STORE, MVT::i1, Custom); >> and implement it in NVPTXTargetLowering::LowerOperation. >> >> But this issue makes a

Hi Dmitry, > So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one > should probably do setOperationAction(ISD::STORE, MVT::i1, Custom); > and implement it in NVPTXTargetLowering::LowerOperation. > > But this issue makes a good point about the code efficiency: I suspect > such expansion will be very ugly in terms of performance. Probably we > can do much better if

On Jul 1, 2008, at 3:42 PM, Richard Osborne wrote: > Evan Cheng wrote: >> On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: >> >> >>> Evan Cheng wrote: >>> >>>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: >>>> >>>> >>>>> I'm trying to write a backend for a target with no hardware

Hi Duncan, Sorry I don't understand your point, could you please explain a little bit more? Why i1 should be declared illegal? Operations on byte-wide types like char or bool are pretty legal, according to PTX spec: "Registers may be typed (signed integer, unsigned integer, floating point, predicate) or untyped. Register size is restricted; aside from predicate registers which are

Hi Dmitry, >> did you declare i1 to be an illegal type? > > No. How? I think it will be considered illegal if you don't add it to any register class. Ciao, Duncan. > > 2012/6/30 Duncan Sands <baldrick at free.fr>: >> Hi Dmitry, >>> So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one >>> should probably do

I may have found a solution to the problem. The attached patch seems to do what I was trying to do. It's a work-around, really. What I have done is split the READ_WORLD node (inputs: Chain; outputs: Flag, Chain) into two nodes: READ_WORLD1 (inputs: Chain; outputs, i32, Chain), and READ_WORLD2 (inputs: i32; outputs: Flag). The pair of nodes is matched by a single pattern in the .td file. Is

2010/1/25 Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com>: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed > > Which made me laugh at first. The corresponding input line was: > >        .align  16 > > Apparently what's going on here is that ".align 16" is ambiguous: on > some architectures

Assuming you're working with an ARM target, you may also hit a problem with the alignment option on the .comm directive. Attached is a first-cut patch for this latter problem. deep On Mon, Jan 25, 2010 at 5:42 PM, Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com> wrote: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed

Hi again, Kind people on #llvm helped me to utilize bugpoint to reduce the previously submitted test case. For record, it code be done with the following command: $ bugpoint -llc-safe test.ll The resulting IR is attached, and it is crashing in the same way. Is it a valid code? dmikushin at hp2:~/forge/kernelgen/branches/tests_lnt/behavior/sincos> llc test.ll.1 This action is not supported