search for: target_vers

On 1/15/2016 2:57 PM, Phil Tomson wrote: > > > I see the following in my SelectCode (in XSTGGenDGISel.inc): > > > /*2235*/ OPC_SwitchOpcode /*2 cases */, 27, > TARGET_VAL(XSTGISD::ADDR_NORMAL),// ->2266 > /*2239*/ OPC_RecordChild0, // #1 = $addr > /*2240*/ OPC_MoveChild, 0, > /*2242*/ OPC_CheckOpcode,

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Pranav Bhandarkar > Sent: Thursday, April 26, 2012 5:24 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] MemRefs in a Load Instruction > > Hi, > > On the hexagon target, I have written a following combiner pattern. >

Hi Daniel, Thanks for replying; I was hoping to get in touch with you on this issue. I had a look at how SelectionIDAG does it when generating the matcher table, and it does consider the implicit defs as additional output. Here is the match table generated for the pattern: /* 0*/ OPC_CheckOpcode, TARGET_VAL(ISD::SIGN_EXTEND), /* 3*/ OPC_MoveChild0, /* 4*/ OPC_CheckOpcode,

On 1/15/2016 1:08 PM, Phil Tomson wrote: > > Ah, I see, the defm is a multi-class so I needed to change it to: > > def: Pat<(load (XSTGADDR_NORMAL tglobaladdr:$addr)), > (LOADI64_RI tglobaladdr:$addr, 0)>; > // Match load from a relocatable address to a load with GRP: > def: Pat<(load (XSTGADDR_USE_GRP tglobaladdr:$addr)), > (LOADI64_RI

In an attempt to add vector registers to my target, I ran into a problem. LLVM started to complain about not being able to infer types from the provided DAG patterns for several classes of instructions. After a discussion on the llvm-dev mailing list and IRC channel the recommendation was to make DAG patterns for these classes of instructions more specific. Which is what was done. However after

Hi, On the hexagon target, I have written a following combiner pattern. ********************************************* def: Pat<(i64 (or (i64 (shl (i64 (extloadi32 (i32 (add IntRegs:$src1, s11_2ExtPred:$offset1)))), (i32 32))), (i64 (zextloadi32 ADDRriS11_2:$src2)))), (i64 (COMBINE_rr

Hi Quentin, Am 03.11.2014 um 23:30 schrieb Quentin Colombet <qcolombet at apple.com>: >> Continuing at 4309 >> Match failed at index 4310 >> Continuing at 4322 >> Morphed node: 0x7fef2a033610: i32 = MVrr 0x7fef2a033610 [ORD=21] >> >> >> Does the add operation become a MOVE instruction, or is this a chain of rules? > > Yes, your add becomes

Le 07/03/2012 17:36, Jim Grosbach a écrit : > On Mar 7, 2012, at 6:23 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi Jim, >> >> Thanks for your response. >> >> Le 06/03/2012 22:54, Jim Grosbach a écrit : >>> Hi Ivan, >>> On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >>>

Hi Quentin, >> Yes, the dags in view-isel-dags and view-legalize-types-dags are correct (the add operations are here and are their results are used) and the dags are the same. > > And what about view-sched-dags? The DAG looks like I described below (*) > This one should give you what has been selected. So if this is not correct, you have indeed a problem in the selection

Thanks Anton and Krzysztof! Here is the dump using the -debug flag. At this point I am not making much sense of this, would it be too much to ask if one of you could walk me through one of these lines? One thing that I didn't point out is that I never defined any separate floating point registers, not sure if this will pose any issue? Thanks again for your time! Jeff jeff at

On Mar 14, 2012, at 7:07 AM, Ivan Llopard wrote: > Le 07/03/2012 17:36, Jim Grosbach a écrit : >> On Mar 7, 2012, at 6:23 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> >>> Hi Jim, >>> >>> Thanks for your response. >>> >>> Le 06/03/2012 22:54, Jim Grosbach a écrit : >>>> Hi Ivan, >>>> On Mar 3,

On Mar 7, 2012, at 6:23 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Jim, > > Thanks for your response. > > Le 06/03/2012 22:54, Jim Grosbach a écrit : >> Hi Ivan, >> On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> >>> Hi, >>> >>> I'm facing a problem in llvm while porting it

Hi Jim, Thanks for your response. Le 06/03/2012 22:54, Jim Grosbach a écrit : > Hi Ivan, > On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi, >> >> I'm facing a problem in llvm while porting it to a new target and I'll >> need some support. >> We have 2 kind of register, one for general purposes (i.e.

On Fri, Feb 19, 2016 at 6:10 AM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2/18/2016 6:01 PM, Rail Shafigulin via llvm-dev wrote: > >> [(set SR:$rD, (Esenciasetflag (i32 GPR:$rA), (i32 >> immSExt16:$imm), (i32 Cond)))]> { >> > > I suspect that the "set SR:$rD" is the problem here. The Esenciasetflag

On 8 March 2014 00:53, Owen Anderson <resistor at mac.com> wrote: > ISDOpcodes.h contains what documentation there is on the semantics of each > opcode. And TargetOpcodes.h for a few of the post-ISel ones (mostly they're in MachineInstr form, but you'll see them with -view-sched-dags, and occasionally before). Tim.

Hi David, > [(set GR32:$rD, globaladdr:$addr)] > It seems to have somehow managed to create a cycle in the DAG, which is > of course wrong. But how? When I write a similar pattern into the ARM .td files and look at (from the build directory) lib/Target/ARM/ARMGenDAGISel.inc, I see: /*56478*/ /*SwitchOpcode*/ 13, TARGET_VAL(ISD::GlobalAddress),// ->56494 /*56481*/