I had retested all the ccmp patches. Bootstrap and no make check regression on X86-64. Bootstrap and no make check regression on AARCH64 qemu.
OK for trunk? Thanks! -Zhenqiang > -----Original Message----- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Zhenqiang Chen > Sent: Monday, October 27, 2014 3:50 PM > To: 'Richard Henderson' > Cc: gcc-patches@gcc.gnu.org > Subject: RE: [Ping] [PATCH, 9/10] aarch64: generate conditional compare > instructions > > > > > -----Original Message----- > > From: Richard Henderson [mailto:r...@redhat.com] > > Sent: Sunday, October 12, 2014 4:46 AM > > To: Zhenqiang Chen; gcc-patches@gcc.gnu.org > > Subject: Re: [Ping] [PATCH, 9/10] aarch64: generate conditional > > compare instructions > > > > On 09/22/2014 11:46 PM, Zhenqiang Chen wrote: > > > +static bool > > > +aarch64_convert_mode (rtx* op0, rtx* op1, int unsignedp) { > > > + enum machine_mode mode; > > > + > > > + mode = GET_MODE (*op0); > > > + if (mode == VOIDmode) > > > + mode = GET_MODE (*op1); > > > + > > > + if (mode == QImode || mode == HImode) > > > + { > > > + *op0 = convert_modes (SImode, mode, *op0, unsignedp); > > > + *op1 = convert_modes (SImode, mode, *op1, unsignedp); > > > + } > > > + else if (mode != SImode && mode != DImode) > > > + return false; > > > + > > > + return true; > > > +} > > > > Hum. I'd rather not replicate too much of the expander logic here. > > > > We could avoid that by using struct expand_operand, > > create_input_operand et al, then expand_insn. That does require that > > the target hooks be given trees rather than rtl as input. > > I had tried to use tree/gimple as input. But the codes was more complexity > than current one. > > And comments in https://gcc.gnu.org/ml/gcc-patches/2014- > 06/msg02027.html > " I suspect it might be better to just hoist any preparation operations above > the entire conditional compare sequence, so that by the time we start the > ccmp expansion we're dealing with operands that are in the 'natural' sizes for > the machine (breaking up the conditional compare sequence for what are > almost side-effect operations sounds like a source of potential bugs). This > would also ensure that the back-end can safely re-order at least some > comparison operations if this leads a workable conditional compare > sequence. " > > I think the mode conversion (to SImode or DImode) is target dependent. > > Thanks! > -Zhenqiang > > >
