This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][gensupport] Add optional attributes field to define_cond_exec
- From: Richard Henderson <rth at redhat dot com>
- To: Kyrylo Tkachov <kyrylo dot tkachov at arm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, sellcey at mips dot com, rguenther at suse dot de
- Date: Mon, 20 May 2013 12:53:47 -0700
- Subject: Re: [PATCH][gensupport] Add optional attributes field to define_cond_exec
- References: <00c001ce557a$d58cab20$80a60160$ at tkachov@arm.com>
On 05/20/2013 09:55 AM, Kyrylo Tkachov wrote:
> For example, a setup like:
>
> (define_attr "predicated" "yes,no" (const_string "no"))
>
> (define_attr "control_attr" "yes,no" (const_string "yes"))
>
>
> (define_attr "enabled" "no,yes"
> (cond [(and (eq_attr "control_attr" "no")
> (and (eq_attr "predicated" "yes")
> (eq_attr "TARGET_RESTRICT_CE" "no")))
> (const_string "no")]
> (const_string "yes"))
>
> (define_cond_exec
> [(match_operator 0 "arm_comparison_operator"
> [(match_operand 1 "cc_register" "")
> (const_int 0)])]
> ""
> ""
> [(set_attr "predicated" "yes")] // <<<< New field
> )
>
> (define_insn ...
> [(set_attr "predicable" "yes")
> (set_attr "control_attr" "yes,no")]) // <<<< disables predicated version of
We have a new define_subst which may help here. I *think* that
define_cond_exec is (or is nearly) a subset of define_subst. On my medium term
to-do list is to support define_cond_exec within gensupport via the
define_subst infrastructure, removing everything except the actual parsing of
define_cond_exec.
Your "predicated" attribute could be mapped to a define_subst substitution.
You could expose this via a true attribute, but I'm not 100% certain that you'd
need to do so.
I havn't thought about all of the ramifications here, but I'd be interested to
hear about your thoughts or experiments down this line.
r~