> > 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
