similar to: [LLVMdev] MemRefs in a Load Instruction

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

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,

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

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

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

Hi, Consider this MI code from the hexagon backend. ------------------------------------------------------------------ 16B %vreg0<def> = COPY %R0<kill>; IntRegs:%vreg0 32B %vreg1<def> = LDriw %vreg0, 0; mem:LD4[%a],IntRegs:%vreg1,%vreg0 48B %vreg2<def> = LDriw_indexed %vreg0<kill>, 4; mem:LD4[%add.ptr] IntRegs:%vreg2,%vreg0 64B

On May 14, 2012, at 4:09 PM, "Pranav Bhandarkar" <pranavb at codeaurora.org> wrote: > Hi, > > Consider this MI code from the hexagon backend. > ------------------------------------------------------------------ > 16B %vreg0<def> = COPY %R0<kill>; IntRegs:%vreg0 > 32B %vreg1<def> = LDriw %vreg0, 0; mem:LD4[%a] >

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

On Jul 8, 2012, at 3:42 PM, Sergei Larin <slarin at codeaurora.org> wrote: > ********** EXPANDING POST-RA PSEUDO INSTRS ********** > ********** Function: main > real copy: %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>, > %D7<imp-def> > replaced by: %R15<def> = TFR %R4, %D7<imp-def> > > The R4 is a subreg of D2 double

hi Tim,guys, it was regarding splitting 16-bit ADDC to two 8-bit ADDC+ADDE. the 8-bit ADDE instruction is defined as: let Constraints="$dst=$op0",mayStore=1, hasSideEffects=0,neverHasSideEffects=1 in def ADDErm: myInstr <0x0, (outs Intregs:$dst) (ins Intregs:$op0,MEMi:$op1), "", [set IntRegs:$dest (adde IntRegs:$op0, (load ADDRi:$op1))] > very unlucky, this

Hello everyone, I am running into an obscure issue with ExpandPostRA. Does anyone recognizes the following: The pass replaces a real copy with a "transfer" instruction: ********** EXPANDING POST-RA PSEUDO INSTRS ********** ********** Function: main real copy: %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>, %D7<imp-def> replaced by:

On Sat, 23 Jun 2012 22:28:55 +0100 Tim Northover <t.p.northover at gmail.com> wrote: > On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote: > > Working on a target I added this pattern: > > > > def : Pat<(v4i64 (load xoaddr:$src)), > > (QVFCTIDb (QVLFDXb xoaddr:$src))>; > > > > I'd like to fix this so that it works

Working on a target I added this pattern: def : Pat<(v4i64 (load xoaddr:$src)), (QVFCTIDb (QVLFDXb xoaddr:$src))>; which represents an actual load followed by a necessary conversion operation. The problem is that when this matches any TokenFactor that was attached to the load node gets attached, not to the inner load instruction, but the outer conversion operation. This is

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 Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote: > Working on a target I added this pattern: > > def : Pat<(v4i64 (load xoaddr:$src)), > (QVFCTIDb (QVLFDXb xoaddr:$src))>; > > I'd like to fix this so that it works correctly: the TokenFactor > inputs should be attached to all inner-most instructions. I'm guessing > this is somewhere in

On Sat, 23 Jun 2012 21:18:37 -0500 Hal Finkel <hfinkel at anl.gov> wrote: > On Sat, 23 Jun 2012 22:28:55 +0100 > Tim Northover <t.p.northover at gmail.com> wrote: > > > On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote: > > > Working on a target I added this pattern: > > > > > > def : Pat<(v4i64 (load xoaddr:$src)), > >