On 18 January 2015 at 21:22, Andrew Pinski wrote:
> On Sun, Jan 18, 2015 at 11:58 AM, Christophe Lyon
> wrote:
>> On 16 January 2015 at 11:54, Marcus Shawcroft
>> wrote:
>>> On 15 January 2015 at 18:18, Richard Henderson wrote:
On 12/15/2014 12:41 AM, Zhenqiang Chen wrote:
> +(define_e
On Sun, Jan 18, 2015 at 11:58 AM, Christophe Lyon
wrote:
> On 16 January 2015 at 11:54, Marcus Shawcroft
> wrote:
>> On 15 January 2015 at 18:18, Richard Henderson wrote:
>>> On 12/15/2014 12:41 AM, Zhenqiang Chen wrote:
+(define_expand "cmp"
+ [(set (match_operand 0 "cc_register" "")
On 16 January 2015 at 11:54, Marcus Shawcroft
wrote:
> On 15 January 2015 at 18:18, Richard Henderson wrote:
>> On 12/15/2014 12:41 AM, Zhenqiang Chen wrote:
>>> +(define_expand "cmp"
>>> + [(set (match_operand 0 "cc_register" "")
>>> +(match_operator:CC 1 "aarch64_comparison_operator"
>
On 15 January 2015 at 18:18, Richard Henderson wrote:
> On 12/15/2014 12:41 AM, Zhenqiang Chen wrote:
>> +(define_expand "cmp"
>> + [(set (match_operand 0 "cc_register" "")
>> +(match_operator:CC 1 "aarch64_comparison_operator"
>> + [(match_operand:GPI 2 "register_operand" "")
>>
On 12/15/2014 12:41 AM, Zhenqiang Chen wrote:
> +(define_expand "cmp"
> + [(set (match_operand 0 "cc_register" "")
> +(match_operator:CC 1 "aarch64_comparison_operator"
> + [(match_operand:GPI 2 "register_operand" "")
> + (match_operand:GPI 3 "aarch64_plus_operand" "")]))]
On 15/12/14 08:41, Zhenqiang Chen wrote:
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Saturday, December 13, 2014 3:26 AM
To: Zhenqiang Chen
Cc: Marcus Shawcroft; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Saturday, December 13, 2014 3:26 AM
> To: Zhenqiang Chen
> Cc: Marcus Shawcroft; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)
>
> > - tree
> - tree lhs = gimple_assign_lhs (g);
> enum machine_mode mode = TYPE_MODE (TREE_TYPE (lhs));
> rtx target = gen_reg_rtx (mode);
> +
> + start_sequence ();
> tmp = emit_cstore (target, icode, NE, cc_mode, cc_mode,
>0, tmp, const0_rtx,
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Tuesday, November 25, 2014 5:25 PM
> To: Zhenqiang Chen
> Cc: Marcus Shawcroft; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)
>
> On 11/25/2014
On 11/26/2014 10:23 AM, Zhenqiang Chen wrote:
> /* Check to make sure CC is not clobbered since prepare_operand might
> generates copy or mode convertion insns, although no test shows
> such insns clobber CC. */
And what do you do if a clobber does happen?
With TER enabled, there's ev
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Tuesday, November 25, 2014 5:25 PM
> To: Zhenqiang Chen
> Cc: Marcus Shawcroft; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)
>
> On 11/25/2014
On 11/25/2014 09:41 AM, Zhenqiang Chen wrote:
> I want to confirm with you two things before I rework it.
> (1) expand_insn needs an optab_handler as input. Do I need to define a
> ccmp_optab with different mode support in optabs.def?
No, look again: expand_insn needs an enum insn_code as input.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Richard Henderson
> Sent: Monday, November 24, 2014 4:57 PM
> To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
> Cc: Marcus Shawcroft
> Subject: Re: [PATCH
On 11/24/2014 06:11 AM, Zhenqiang Chen wrote:
> Expand pass always uses sign-extend to represent constant value. For the
> case in the patch, a 8-bit unsigned value "252" is represented as "-4",
> which pass the ccmn check. After mode conversion, "-4" becomes "252", which
> leads to mismatch.
This
On Sun, Nov 23, 2014 at 9:11 PM, Zhenqiang Chen wrote:
> Hi,
>
> Expand pass always uses sign-extend to represent constant value. For the
> case in the patch, a 8-bit unsigned value "252" is represented as "-4",
> which pass the ccmn check. After mode conversion, "-4" becomes "252", which
> leads
Hi,
Expand pass always uses sign-extend to represent constant value. For the
case in the patch, a 8-bit unsigned value "252" is represented as "-4",
which pass the ccmn check. After mode conversion, "-4" becomes "252", which
leads to mismatch.
The patch adds another operand check after mode conve
16 matches
Mail list logo
