Current limitations of define_subst

Current limitations of define_subst

[Colin McEwan]

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

Re: Current limitations of define_subst

[Richard Sandiford]

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