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 wi
> 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
> > 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_
> 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 encounte
> > 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 triggers the creation of
> cond_exec
> > variants for all of
> 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 triggers the creation of cond_exec
> variants for all of the alternative
> > 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
> mak
> 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
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
> - 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
Hi Michael,
> Hi Kyrylo, Richard,
>
> > What would be the function of (set_attr "ds_predicable" "yes") ?
> > Doesn't the use of 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 connected
>
Hi Kyrylo, Richard,
> What would be the function of (set_attr "ds_predicable" "yes") ?
> Doesn't the use of 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 connected
subst-attributes in the patt
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 "d
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 p
> > 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
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 "cont
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 v
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 an
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")
>
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
20 matches
Mail list logo
