> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Tuesday, November 05, 2013 4:39 AM
> To: Zhenqiang Chen
> Cc: Richard Earnshaw; 'Richard Biener'; GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
>
>
On 11/04/2013 08:00 PM, Zhenqiang Chen wrote:
> Thanks. I add a new hook. The default function will return -1 if the target
> does not care about the order.
>
> +DEFHOOK
> +(select_ccmp_cmp_order,
> + "For some target (like ARM), the order of two compares is sensitive for\n\
> +conditional compare
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Friday, November 01, 2013 12:27 AM
> To: Zhenqiang Chen
> Cc: Richard Earnshaw; 'Richard Biener'; GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
>
>
d Henderson [mailto:r...@redhat.com]
>> Sent: Monday, October 28, 2013 11:07 PM
>> To: Zhenqiang Chen; Richard Earnshaw; 'Richard Biener'
>> Cc: GCC Patches
>> Subject: Re: [PATCH 1/n] Add conditional compare support
>>
>> On 10/28/2013 01:32 AM, Zhenqia
On 10/31/2013 02:06 AM, Zhenqiang Chen wrote:
> With two compares, we might swap the order of the two compares to get a
> valid combination. This is what current ARM does (Please refer
> arm_select_dominace_cc_mode, cmp_and, cmp_ior, and_scc_scc and ior_scc_scc).
> To improve gen_ccmp_first, we nee
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Thursday, October 31, 2013 4:14 AM
> To: Zhenqiang Chen
> Cc: Richard Earnshaw; 'Richard Biener'; GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
>
>
> +/* RCODE0, RCODE1 and a valid return value should be enum rtx_code.
> + TCODE should be enum tree_code.
> + Check whether two compares are a valid combination in the target to
> generate
> + a conditional compare. If valid, return the new compare after
> combination.
> + */
> +DEFHOOK
Il 18/09/2013 11:45, Zhenqiang Chen ha scritto:
> +;; Expand conditional compare according to the instruction patterns.
> +(define_expand "conditional_compare"
> + [(set (match_operand 0 "s_register_operand" "")
> + (match_operator 1 ""
> + [(match_operator:SI 2 "arm_comparison_operator"
On Wed, 30 Oct 2013, Zhenqiang Chen wrote:
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Hans-Peter Nilsson
> > One thing I don't see other people mentioning, is that this patch has just
> too
> > much code inside #if
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Hans-Peter Nilsson
> Sent: Tuesday, October 29, 2013 10:38 AM
> To: Zhenqiang Chen
> Cc: Richard Earnshaw; 'Richard Biener'; GCC Patches
&g
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Monday, October 28, 2013 11:07 PM
> To: Zhenqiang Chen; Richard Earnshaw; 'Richard Biener'
> Cc: GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
>
>
On Tue, 22 Oct 2013, Zhenqiang Chen wrote:
> ChangeLog:
> 2013-10-22 Zhenqiang Chen
>
> * config/arm/arm.c (arm_fixed_condition_code_regs, arm_ccmode_to_code,
> arm_select_dominance_ccmp_mode): New functions.
> (arm_select_dominance_cc_mode_1): New function extracted from
>
On 10/28/2013 01:32 AM, Zhenqiang Chen wrote:
> Patch is updated according to your comments. Main changes are:
> * Add two hooks: legitimize_cmp_combination and legitimize_ccmp_combination
> * Improve document.
No, these are not the hooks I proposed.
You should *not* have a ccmp_optab, because th
On 10/24/2013 09:37 AM, Richard Earnshaw wrote:
> It still needs to put out the right final condition based on the
> comparisons that were previously done. At least traditionaly (in the
> existing ARM code) the comparison was just EQ or NE even if the original
> tests were inequalities; so the onl
On 10/24/2013 09:24 AM, Richard Earnshaw wrote:
> On 24/10/13 17:15, Richard Henderson wrote:
>> On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
Why would you need to encode comparisons in CCmodes?
That looks like a mis-design to me.
>>>
>>> The CCmodes are used to check whether the result
On 24/10/13 17:26, Richard Henderson wrote:
> On 10/24/2013 09:24 AM, Richard Earnshaw wrote:
>> On 24/10/13 17:15, Richard Henderson wrote:
>>> On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
> Why would you need to encode comparisons in CCmodes?
> That looks like a mis-design to me.
>>
On 24/10/13 17:15, Richard Henderson wrote:
> On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
>>> Why would you need to encode comparisons in CCmodes?
>>> That looks like a mis-design to me.
>>
>> The CCmodes are used to check whether the result of a previous conditional
>> compare can combine with
On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
>> Why would you need to encode comparisons in CCmodes?
>> That looks like a mis-design to me.
>
> The CCmodes are used to check whether the result of a previous conditional
> compare can combine with current compare. By changing it to rtx_code, I can
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Thursday, October 24, 2013 12:14 AM
> To: Zhenqiang Chen; Richard Earnshaw; 'Richard Biener'
> Cc: GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
> +static enum rtx_code
> +arm_ccmode_to_code (enum machine_mode mode)
> +{
> + switch (mode)
> +{
> +case CC_DNEmode:
> + return NE;
Why would you need to encode comparisons in CCmodes?
That looks like a mis-design to me.
> +Conditional compare instruction. Operand 2 and 5 are RTL
ect: RE: [PATCH 1/n] Add conditional compare support
>
>
>
> > -Original Message-
> > From: Richard Earnshaw
> > Sent: Thursday, September 19, 2013 5:13 PM
> > To: Zhenqiang Chen
> > Cc: 'Richard Biener'; GCC Patches
> > Subject: Re:
> -Original Message-
> From: Richard Earnshaw
> Sent: Thursday, September 19, 2013 5:13 PM
> To: Zhenqiang Chen
> Cc: 'Richard Biener'; GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
>
> On 18/09/13 10:45, Zhenqiang Chen wro
On 18/09/13 10:45, Zhenqiang Chen wrote:
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, August 27, 2013 8:18 PM
>> To: Richard Earnshaw
>> Cc: Zhenqiang Chen; GCC Patches
>> Subject: Re: [PAT
Hi,
On Wed, 18 Sep 2013, Zhenqiang Chen wrote:
> The patch is updated according to your comments. It is a basic support,
> which does not touch ifcombine and jump related optimizations yet.
>
> Current method is:
> 1) In fold-const, if HAVE_conditional_compare, set
> LOGICAL_OP_NON_SHORT_CIRCUIT
On Wed, Sep 18, 2013 at 11:45 AM, Zhenqiang Chen wrote:
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, August 27, 2013 8:18 PM
>> To: Richard Earnshaw
>> Cc: Zhenqiang Chen; GCC Patches
>> S
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, August 27, 2013 8:18 PM
> To: Richard Earnshaw
> Cc: Zhenqiang Chen; GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
>
> On Tue, Aug 27,
On Tue, Aug 27, 2013 at 1:56 PM, Richard Earnshaw wrote:
> On 27/08/13 12:10, Richard Biener wrote:
>> What's this for and what's the desired semantics? I don't like having
>> extra tree codes for this. Is this for a specific instruction set
>> feature?
>
> The background is to support the condit
On 27/08/13 12:10, Richard Biener wrote:
> What's this for and what's the desired semantics? I don't like having
> extra tree codes for this. Is this for a specific instruction set
> feature?
The background is to support the conditional compare instructions in ARM
(more effectively) and AArch64 a
On Wed, Aug 21, 2013 at 12:23 PM, Zhenqiang Chen wrote:
> Hi,
>
> The attached patch is the basic support for conditional compare (CCMP). It
> adds
> a set of keywords on TREE to represent CCMP:
>
> DEFTREECODE (TRUTH_ANDIF_LT_EXPR, "truth_andif_lt_expr", tcc_ccomparison, 3)
> DEFTREECODE (TRUTH_A
29 matches
Mail list logo
