Segher Boessenkool <seg...@kernel.crashing.org> writes: > On Wed, Jun 26, 2019 at 07:27:20PM +0530, Prathamesh Kulkarni wrote: >> combine then does following combinations: >> >> Trying 7 -> 9: >> 7: r90:V2DI=r89:V2DI>r93:V2DI >> REG_DEAD r93:V2DI >> REG_DEAD r89:V2DI >> 9: r91:V2DF=r90:V2DI#0 >> REG_DEAD r90:V2DI >> Successfully matched this instruction: >> (set (subreg:V2DI (reg:V2DF 91) 0) >> (gt:V2DI (reg:V2DI 89) >> (reg:V2DI 93))) >> allowing combination of insns 7 and 9 >> >> Trying 6, 9 -> 10: >> 6: r89:V2DI=const_vector >> 9: r91:V2DF#0=r89:V2DI>r93:V2DI >> REG_DEAD r89:V2DI >> REG_DEAD r93:V2DI >> 10: r87:SI=unspec[r91:V2DF] 43 >> REG_DEAD r91:V2DF >> Successfully matched this instruction: >> (set (reg:SI 87) >> (unspec:SI [ >> (lt:V2DF (reg:V2DI 93) >> (const_vector:V2DI [ >> (const_int 0 [0]) repeated x2 >> ])) >> ] UNSPEC_MOVMSK)) > > Both of these are obviously correct, they are simple substitutions. > If this does not do what you want, the problem is elsewhere, not in > combine, afaics?
"Obviously" correct seems a stretch :-) We can only fold: (subreg:V2DF (foo:V2DI X) 0) to: (foo:V2DF X) for certain operations. E.g. it'd be wrong to do it for foo=plus. IMO it's wrong for comparisons too. A comparison between integers that produces a floating-point result makes no sense, whatever the target thinks about it. >> Is the above folding correct, since lt has V2DF mode, >> and casting -1 (literally) to DFmode would result in -NaN ? > > Combine does not introduce any of that, it was there already. The original insns had an lt:V2DI between V2DI inputs and a V2DF subreg of the result. It's combine that turns that into a lt:V2DF between V2DI inputs. Richard >> Also, should result of lt be having only integral modes ? > > Apparently your machine description likes this fine. Combine does not > ask questions. > > > Segher
