> -----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
