Segher Boessenkool <seg...@kernel.crashing.org> writes: > Hi, > > [ Please don't use application/octet-stream attachments. Thanks! ] > > On Wed, Oct 16, 2019 at 04:24:29PM +0000, Yuliang Wang wrote: >> +;; Unpredicated bitwise select. >> +(define_insn "*aarch64_sve2_bsl<mode>" >> + [(set (match_operand:SVE_I 0 "register_operand" "=w, ?&w") >> + (xor:SVE_I >> + (and:SVE_I >> + (xor:SVE_I >> + (match_operand:SVE_I 1 "register_operand" "<bsl_1st>, w") >> + (match_operand:SVE_I 2 "register_operand" "<bsl_2nd>, w")) >> + (match_operand:SVE_I 3 "register_operand" "w, w")) >> + (match_dup BSL_3RD)))] > > This isn't canonical RTL. Does combine not simplify this? > > Or, rather, it should not be what we canonicalise to: nothing is defined > here.
But when nothing is defined, let's match what we get :-) If someone wants to add a new canonical form then the ports should of course adapt, but until then I think the patch is doing the right thing. > We normally get something like > > Trying 7, 8 -> 9: > 7: r127:SI=r130:DI#4^r125:DI#4 > REG_DEAD r130:DI > 8: r128:SI=r127:SI&0x20000000 > REG_DEAD r127:SI > 9: r126:SI=r128:SI^r125:DI#4 > REG_DEAD r128:SI > REG_DEAD r125:DI > Successfully matched this instruction: > (set (reg:SI 126) > (ior:SI (and:SI (subreg:SI (reg:DI 130) 4) > (const_int 536870912 [0x20000000])) > (and:SI (subreg:SI (reg/v:DI 125 [ yD.2902+-4 ]) 4) > (const_int -536870913 [0xffffffffdfffffff])))) > > If the mask is not a constant, we really shouldn't generate a totally > different form. The xor-and-xor form is very hard to handle, too. > > Expand currently generates this, because gimple thinks this is simpler. > I think this should be fixed. But the constant form is effectively folding away the NOT. Without it the equivalent rtl uses 4 operations rather than 3: (ior (and A C) (and B (not C))) And folding 4 operations gets us into 4-insn combinations, which are obviously more limited (for good reason). As you say, it's no accident that we get this form, it's something that match.pd specifically chose. And I think there should be a strong justification for having an RTL canonical form that reverses a gimple decision. RTL isn't as powerful as gimple and so isn't going to be able to undo the gimple transforms in all cases. Thanks, Richard
