On Mon, Apr 30, 2012 at 3:10 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Mon, Apr 30, 2012 at 02:54:05PM +0200, Uros Bizjak wrote: >> > My recent changes to zero_extend expanders should handle this >> > automatically, and will undo generation of zero_extend pattern. Please >> > see zero_extend<mode>si2_and expander, and how it handles >> > TARGET_ZERO_EXTEND_WITH_AND targets. >> >> Attached patch implements this idea. In addition, it fixes the >> splitter to not change output mode of zero_extension from HImode and >> QImode from DImode to SImode. Although they generate the same >> instruction, I think we should better keep original mode here. > > Thanks. I was trying this morning slightly different patch for the same, > but strangely it failed bootstrap, and didn't get around to analysing > why a mem store had (zero_extend (subreg (reg))) on a RHS.
Maybe it was due to slightly wrong splitter? I was changing both, the expander and the splitter in parallel, and didn't see any failure you mentioned... >> + operands[1] = gen_lowpart (mode, operands[1]); >> + >> + if (GET_MODE (operands[0]) == DImode) >> + insn = (mode == SImode) >> + ? gen_zero_extendsidi2 >> + : (mode == HImode) >> + ? gen_zero_extendhidi2 >> + : gen_zero_extendqidi2; >> + else if (GET_MODE (operands[0]) == SImode) >> + insn = (mode == HImode) >> + ? gen_zero_extendhisi2 >> + : gen_zero_extendqisi2; >> + else if (GET_MODE (operands[0]) == HImode) >> + insn = gen_zero_extendqihi2; >> else >> - ix86_expand_binary_operator (AND, <MODE>mode, operands); >> + gcc_unreachable (); >> + >> + emit_insn (insn (operands[0], operands[1])); > > IMHO you should use <MODE>mode instead of GET_MODE (operands[0]) > in all of the above, then the compiler can actually optimize > it at compile time. You are right, I will change this in an incremental patch. Thanks, Uros.
