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: Wed, 22 May 2013 10:03:51 -0700
- Subject: Re: [PATCH][gensupport] Add optional attributes field to define_cond_exec
- References: <00c001ce557a$d58cab20$80a60160$ at tkachov@arm.com> <519A7F4B dot 2090506 at redhat dot com> <00ce01ce563c$70d55a20$52800e60$ at tkachov@arm.com> <00db01ce56d2$5fb5bd70$1f213850$ at tkachov@arm.com>
On 05/22/2013 02:54 AM, Kyrylo Tkachov wrote:
> From what I understand, using define_subst would mean creating a
> define_subst for every pattern that can be "predicable"? There are at least
> 600 predicable patterns in the arm backend, so that would be infeasible.
No, define_subst works across patterns, keyed by attributes. Exactly like
cond_exec, really.
But what you ought to be able to do right now is
(define_subst "ds_predicable"
[(match_operand 0)]
""
[(cond_exec (blah) (match_dup 0))])
(define_subst_attr "ds_predicable_enabled" "ds_predicable" "no" "yes"0
(define_insn "blah"
[(blah)]
""
"@
blah
blah"
[(set_attr "ds_predicable" "yes")
(set_attr "ds_predicated" "<ds_predicable_enabled>")])
At which point you can define "enabled" in terms of ds_predicated plus whatever.
With a small bit of work we ought to be able to move that ds_predicated
attribute to the define_subst itself, so that you don't have to replicate that
set_attr line N times. I think that's more or less what you were suggesting
with your cond_exec extension, yes?
r~