[PATCH][gensupport] Add optional attributes field to define_cond_exec

[Kyrylo Tkachov]

Hi all,

While working with conditional execution and in particular with
define_cond_exec, I would like to add an attribute to cond_exec
patterns that are produced through define_cond_exec. This is done by adding
an attributes vector to the define_cond_exec construct.
When a pattern is then processed through define_cond_exec, the attributes
vector is appended to the existing attributes.
 This would allow us to, for example, disable the predicable variant of an
insn
based on a non-constant variable.

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
the second alternative when TARGET_RESTRICT_CE is set

would let us disable the conditional variant of an insn by setting its
control_attr attribute to "no"
when the variable TARGET_RESTRICT_CE is true.
This new field for define_cond_exec is optional, and leaving it out should
not affect any backend that does not use it.

This would be a very useful feature for the arm backend to use, and without
it,
dynamically disabling conditional variants of insns
(i.e. dependent on a compiler flag)
involves a lot of pattern duplication and ugliness.

Patch has been bootstrapped on an arm-none-linux-gnueabihf target with
running on a Cortex-A15 and regtested.
Also, bootstrapped on x86_64-unknown-linux-gnu.
I've been working and testing on the arm backend, however I noticed that
ia64 and c6x use define_cond_exec as well,
so I'm cc'ing Steve. Would it be possible for you to confirm that this
doesn't break ia64? I compared the outputs of the gen*
programs with and without the patch and didn't see anything bad (the way
define_cond_exec is parsed changes due to the format change)

Any other feedback on the patch would, of course, be very appreciated.

Ok for trunk if no objections?

Thanks,
Kyrill

2013-05-20  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

	* rtl.def: Add extra third optional field to define_cond_exec.
	* gensupport.c (process_one_cond_exec): Process attributes from
	define_cond_exec.
	* doc/md.texi: Document third field in define_cond_exec.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02-define_cond_exec.patch
Type: application/octet-stream
Size: 2998 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130520/6ada65b7/attachment.obj>