Colin McEwan via Gcc <gcc@gcc.gnu.org> writes: > Hi all, > > I was wondering if anyone understands the rationale behind the current > limitations on (define_subst), ie. working only on (define_insn) and > (define_expand). > > A lot of md cleanup, as well as extra patterns for combiner use, could be > enabled by supporting (define_split) / (define_insn_and_split) / > (define_peephole2) so I've had a very brief look at adding support for > these constructs, and from what I see there are only a few barriers > standing in the way. > > 1. attributes are used to store iterator state. This is fine for insns and > expands,, but splits and peephole2- do not have attributes. Some alternate > storage could be used, or attributes could added for splits and peephole2s. > > 2. splits and peephole2s will have two RTL patterns which the transform > might be intended to apply to. Adding an attribute to (define_subst) to > flag whether it applies to 'old', 'new' or both RTL patterns in the > definition seems a reasonable change to support this. > > Does anyone have any insight into anything else that would stop this from > working?
Thanks for looking at this. Extending define_subst to support other constructs sounds useful. Normally the define_subst is triggered by the use of special string attributes, but define_splits don't have the names or (like you say) attributes in which these special attribute would typically be used. Is the idea to apply the define_subst to all define_splits whose patterns match? Or would there be some other trigger for using the define_subst? Apart from that, I don't think there's any fundamental reason why define_subst hasn't been made to work with other constructs. Thanks, Richard
