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

["Kyrylo Tkachov" <kyrylo dot tkachov at arm dot com>]

> > 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.
> 
> An clearer example of what I'm trying to achieve can be found here:
> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01139.html
> 
> I've been trying to wrap my head around define_subst, and it was
> considered
> initially, but from the online documentation
> (http://gcc.gnu.org/onlinedocs/gccint/Define-Subst.html#Define-Subst)
> I couldn't think of a way to use it.
> 
> What I want essentially, is to disable the cond_exec variant of an insn
> based on some variable.
> This stems from the fact that the "predicable" attribute cannot depend
> on
> anything else
> (has to be a compile-compile time constant).
> 
> >
> > 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.

So, thinking about it a bit more...
I can see how define_subst is a generalised version of define_cond_exec,
but what I need in my case is more fine-grained control over the
alternatives.
I'd like to say, for example, that the predicated version of the 3rd
alternative
is disabled for, say, TARGET_RESTRICT_CE. I don't think define_subst would
allow me
to do this in its current form.

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.

Kyrill