> > 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 that is tied to that particular > > define_subst. > It looks hacky indeed, but afaiu, current define_cond_exec doesn't > satisfy your needs as well - you want to add something to it, > right? > So I thought that probably it's better to consider using > define_subst > (as a possible replacement of define_cond_exec in some future) - > and > maybe adjusting it to your needs and making it look less 'hacky', > than > changing define_cond_exec. > > Anyway, points you mentioned are quite reasonable, so it's all up > to you:)
So the change I propose to define_cond_exec is self-contained and doesn't require rewriting large parts of the backend to use define_subst. The attributes field for define_cond_exec will be optional and should not affect any backends that do not use it. I think any work to replace the behind-the-scenes implementation of define_cond_exec by define_subst in the future can be discussed when there is a plan in place for that. 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? Thanks, Kyrill
