Segher Boessenkool <> writes:
> On Wed, Aug 09, 2017 at 05:54:40PM +0100, Richard Sandiford wrote:
>> Segher Boessenkool <> writes:
>> > We need it, for example, to properly cost the various define_insn_and_split
>> > (for which "type" is only an approximation, and is woefully inadequate
>> > for determining cost).
>> But define_insn_and_splits could override the cost explicitly if they
>> need to.  That seems neater than testing for them in C.
> All 190 of them?  Not counting those that are define_insn+define_split
> (we still have way too many of those).
> Neat, indeed, but not altogether practical :-(

Are there really 190 separate cases though?  If not, then it's
possible to have separate attributes that describe various forms of
multi-instruction pattern.  These can then get mapped automatically
to the appropriate "type" and often can also be used to set a
conservatively-correct "length".


Reply via email to