> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> Based on my understanding of your answer quoted above, I'll commit
> it as is, despite not having been able to come up with a testcase. I'll
> wait tomorrow to do so though in case y
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, April 28, 2015 12:27 AM
> OK. No need for heroics -- give it a shot, but don't burn an insane
> amount of time on it. If we can't get to a reasonable testcase, then so
> be it.
Ok, I tried but really didn't managed to create a testcase.
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, April 28, 2015 12:27 AM
> To: Thomas Preud'homme; 'Eric Botcazou'
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, combine] Try REG_EQUAL for nonzero_bits
>
> On 04/27/2015 04:26 AM, Thomas Pr
On 04/27/2015 04:26 AM, Thomas Preud'homme wrote:
From: Jeff Law [mailto:l...@redhat.com]
Sent: Saturday, April 25, 2015 3:00 AM
Do you have a testcase where this change can result in better generated
code. If so please add that testcase. It's OK if it's ARM specific.
Hi Jeff,
Last time I tr
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Saturday, April 25, 2015 3:00 AM
> Do you have a testcase where this change can result in better generated
> code. If so please add that testcase. It's OK if it's ARM specific.
Hi Jeff,
Last time I tried I couldn't reduce the code to a small tes
On 02/09/2015 07:00 PM, Thomas Preud'homme wrote:
And this is part 2.
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
Once this is done, the same thing needs to be applied to XEXP
(reg_equal, 0)
before it is sent to nonzero_bits.
-
And this is part 2.
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
>
> Once this is done, the same thing needs to be applied to XEXP
> (reg_equal, 0)
> before it is sent to nonzero_bits.
>
>
> > - /* Don't call nonzero_bits if it c
> Thanks for the comments. Patch is updated.
>
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 1808f97..2e865d7 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -1603,6 +1603,28 @@ setup_incoming_promotions (rtx_insn *first)
> }
> }
>
> +/* Update RSP from INSN's REG_EQUAL note
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
> Sent: Monday, November 24, 2014 5:41 PM
> To: Zhenqiang Chen
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, combine] Try REG_E
> Thanks for the comments. I will compare the two nonzero_bits from src and
> REG_EQUAL. Then select the smaller one.
They are masks so you can simply AND them before ORing the result.
> Do you know why it use " SET_SRC (set)" other than "src" for
> num_sign_bit_copies?
>
> If it is "src", I sho
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Saturday, November 22, 2014 6:15 PM
> To: Zhenqiang Chen
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, combine] Try REG_EQUAL for nonzero_bits
>
> > The patch tries t
> The patch tries to use REG_EQUAL to get more precise info for nonzero_bits,
> which helps to remove unnecessary zero_extend.
>
> Here is an example when compiling Coremark, we have rtx like,
>
> (insn 1244 386 388 47 (set (reg:SI 263 [ D.5767 ])
> (reg:SI 384 [ D.5767 ])) 786 {*thumb2_m
12 matches
Mail list logo
