RE: [Ping] [PATCH, 9/10] aarch64: generate conditional compare instructions
-Original Message- From: Richard Henderson [mailto:r...@redhat.com] Sent: Wednesday, November 05, 2014 9:42 PM To: Zhenqiang Chen Cc: gcc-patches@gcc.gnu.org Subject: Re: [Ping] [PATCH, 9/10] aarch64: generate conditional compare instructions On 11/05/2014 10:05 AM, Zhenqiang Chen wrote: 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? No patch? Or what is it that you're wanting approval for? Sorry! The patch is attached. In fact, there is no real change from its original version: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01914.html And there is no comment after https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02717.html So I retest it and ping again. Thanks! -Zhenqiang 9-gen-ccmp.patch Description: Binary data
Re: [Ping] [PATCH, 9/10] aarch64: generate conditional compare instructions
+ /* Generate insn to match ccmp_and/ccmp_ior. */ + target = gen_rtx_REG (mode, CC_REGNUM); + emit_insn (gen_rtx_SET (VOIDmode, target, + gen_rtx_fmt_ee (COMPARE, VOIDmode, + bit_op, const0_rtx))); Invalid mode for the compare; should be mode. Otherwise ok. r~
RE: [Ping] [PATCH, 9/10] aarch64: generate conditional compare instructions
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
Re: [Ping] [PATCH, 9/10] aarch64: generate conditional compare instructions
On 11/05/2014 10:05 AM, Zhenqiang Chen wrote: 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? No patch? Or what is it that you're wanting approval for? r~
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
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.
r~
