Any comments/suggestions on my implementation of the idea are very
welcome.
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01093.html
Otherwise, OK for trunk?
Ping?
Thanks,
Kyrill
On 06/03/2013 04:06 AM, Kyrylo Tkachov wrote:
Any comments/suggestions on my implementation of the idea are very
welcome.
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01093.html
Otherwise, OK for trunk?
Ping?
Ok.
If we ever get serious about re-implementing define_cond_exec with
more
I agree that it is possible to use define_subst (apart from the
fact
that it doesn't support define_insn_and_split yet). It's just
that I
think it looks hacky and makes the patterns look
less readable if the reader has to remember that predication is
implicit
when a subst_attr is
I agree that it is possible to use define_subst (apart from the fact
that it doesn't support define_insn_and_split yet). It's just that I
think it looks hacky and makes the patterns look
less readable if the reader has to remember that predication is implicit
when a subst_attr is encountered
Hi Michael,
- What about define_insn_and_split? Currently, we can define
predicable
for a define_insn_and_split,
Yes, you're right. Currently define_subst cannot be applied to
define_insn_and_split. That's not implemented yet because I didn't
see
a real usages of define_substs with these
Unfortunately, that is a strong point against define_subst in my case,
since on arm we have more than 400 predicable patterns, of we which we
might want to modify dozens to perform this cond_exec restriction.
And creating custom subst-attributes for each one would really make
things hard to
Unfortunately, that is a strong point against define_subst in my
case,
since on arm we have more than 400 predicable patterns, of we
which we
might want to modify dozens to perform this cond_exec
restriction.
And creating custom subst-attributes for each one would really
make
things
As things stand now, if predicable is set to no for a particular
alternative, the value of control_attr is irrelevant, that alternative
will never have a cond_exec version. In your scheme, however,
the presence of subst_predicated triggers the creation of cond_exec
variants for all of the
As things stand now, if predicable is set to no for a
particular
alternative, the value of control_attr is irrelevant, that
alternative
will never have a cond_exec version. In your scheme, however,
the presence of subst_predicated triggers the creation of
cond_exec
variants for all of
Hi Richard,
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
Hi Michael,
Hi Kyrylo, Richard,
What would be the function of (set_attr ds_predicable yes) ?
Doesn't the use of ds_predicable_enabled already trigger the
substitution?
To use define subst one doesn't need to write (set_attr
ds_predicable yes) - it's triggered by mentioning any of
- What about define_insn_and_split? Currently, we can define predicable
for a define_insn_and_split,
Yes, you're right. Currently define_subst cannot be applied to
define_insn_and_split. That's not implemented yet because I didn't see
a real usages of define_substs with these (though I'm not
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
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
Hi Steven,
This would allow us to, for example, disable the predicable variant
of an
insn
based on a non-constant variable.
Is there a reason why you can't use attribute enabled for this?
The problem stems from the fact that the predicable attribute cannot have
a dynamic value.
Hi Richard,
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
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
On Mon, May 20, 2013 at 6:55 PM, Kyrylo Tkachov wrote:
This would allow us to, for example, disable the predicable variant of an
insn
based on a non-constant variable.
Is there a reason why you can't use attribute enabled for this?
Ciao!
Steven
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
On Mon, 2013-05-20 at 17:55 +0100, Kyrylo Tkachov wrote:
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 am not at HP anymore and
20 matches
Mail list logo
