search for: f4rc

I have been doing some playing with the patterns that define complex instructions, and I saw a behavior that doesn't look right. I think its a bug in the PPC backend. The 32-bit PPC .td file defines a pattern for the fnmsubs instruction like this: def : Pat<(fsub F4RC:$B, (fmul F4RC:$A, F4RC:$C)), (FNMSUBS F4RC:$A, F4RC:$C, F4RC:$B)>, Requires<[FPContractions]>; The unique feature of this parttern is that it maps a pair of LLVM IR instructions into a single PPC instruction. def FNMSUBS : AForm_1<59, 30,(outs F4RC:$FRT), (i...

...s i32:$dst), (ins i32:$src1, i32:$src2), > "some assembler", > [(set $dst, (Op $src1, $src2))]>; >From the PPC changes, I see that this is already possible under a slightly different form: def FSUBS : AForm_2<59, 20, (outs F4RC:$FRT), (ins F4RC:$FRA, F4RC:$FRB), "fsubs $FRT, $FRA, $FRB", FPGeneral, - [(set F4RC:$FRT, (fsub F4RC:$FRA, F4RC:$FRB))]>; + [(set f32:$FRT, (fsub f32:$FRA, f32:$FRB))]>; Sebastian -- Qualcomm Innovation Center, Inc...

Jakob Stoklund Olesen wrote: > I have updated TableGen to support a new format for instruction selection patterns. > > Before: > > def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>; > > After: > > def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>; > > Since the pattern matching happens on a DAG with type labels, not

I have updated TableGen to support a new format for instruction selection patterns. Before: def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>; After: def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>; Since the pattern matching happens on a DAG with type labels, not register classes, I think it makes more sense to specify types directly on the input

...debug info) is actually defined in two blocks. I wonder if we can fix this by making the transformation simpler, that is, instead of doing: %vreg12<def> = COPY %vreg7; VSSRC:%vreg12,%vreg7 %vreg12<def,tied1> = XSMADDASP %vreg12<tied0>, %vreg0, %vreg4; VSSRC:%vreg12,%vreg0 F4RC:%vreg4 -> %vreg0<def,tied1> = XSMADDMSP %vreg0<tied0>, %vreg4, %vreg7; VSSRC:%vreg0,%vreg7 F4RC:%vreg4 , we do: %vreg12<def> = COPY %vreg7; VSSRC:%vreg12,%vreg7 %vreg12<def,tied1> = XSMADDASP %vreg12<tied0>, %vreg0, %vreg4; VSSRC:%vreg12,%vreg0 F4RC:%vre...

...nt cycle. Without looking forward, I don't understand how it could know how long the pipeline hazard will last. It looks like this may have something to do with the height. Can you explain how that is supposed to work? For the specific example: We start with the initial store... GPRC: 4 / 31 F4RC: 1 / 31 Examining Available: Height 2: SU(102): 0x2c03f70: ch = STFSX 0x2c03c70, 0x2bf3910, 0x2c03870, 0x2c03e70<Mem:ST4[%arrayidx6.14](align=8)(tbaa=!"float")> [ORD=94] [ID=102] Height 2: SU(97): 0x2c03470: ch = STFSX 0x2c03170, 0x2bf3910, 0x2c02c60, 0x2c03370<Mem:ST4[%arrayid...

...t > understand how it could know how long the pipeline hazard will last. > > It looks like this may have something to do with the height. Can you > explain how that is supposed to work? > > For the specific example: We start with the initial store... > > GPRC: 4 / 31 > F4RC: 1 / 31 > > Examining Available: > Height 2: SU(102): 0x2c03f70: ch = STFSX 0x2c03c70, 0x2bf3910, > 0x2c03870, 0x2c03e70<Mem:ST4[%arrayidx6.14](align=8)(tbaa=!"float")> > [ORD=94] [ID=102] > > Height 2: SU(97): 0x2c03470: ch = STFSX 0x2c03170, 0x2bf3910, 0x2c0...

...now how long the pipeline hazard will last. >> >> It looks like this may have something to do with the height. Can you >> explain how that is supposed to work? >> >> For the specific example: We start with the initial store... >> >> GPRC: 4 / 31 >> F4RC: 1 / 31 >> >> Examining Available: >> Height 2: SU(102): 0x2c03f70: ch = STFSX 0x2c03c70, 0x2bf3910, >> 0x2c03870, 0x2c03e70<Mem:ST4[%arrayidx6.14](align=8)(tbaa=!"float")> >> [ORD=94] [ID=102] >> >> Height 2: SU(97): 0x2c03470: ch = STFSX...

On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > Here's my "thought experiment" (from PR11589): I have a bunch of > load-fadd-store chains to schedule. A store takes two cycles to clear > its last pipeline stage. The fadd takes longer to compute its result > (say 5 cycles), but can sustain a rate of 1 independent add per cycle. > As the scheduling is bottom-up, it

On Mon, 2011-12-19 at 22:14 -0800, Andrew Trick wrote: > On Dec 19, 2011, at 3:19 PM, Hal Finkel wrote: > > > On Mon, 2011-12-19 at 07:41 -0800, Andrew Trick wrote: > >> On Dec 19, 2011, at 6:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> > >>> On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > >>> Now, to generate the best