Re: [MIPS] MADD issue

[Richard Sandiford <richard at codesourcery dot com>]

Ian Lance Taylor <iant@google.com> writes:
> Richard Sandiford <richard@codesourcery.com> writes:
>> I realise no-one else has spoken out in support of me, so perhaps
>> I'm in a minority of one here.  But it does seem to me that in the
>> Tree-SSA world, it makes less sense to duplicate standard optabs
>> in the backend purely for the reason of keeping DImode arithmetic
>> around as DImode arithmetic for longer.
>
> The main issue I know of is the RTL level loop optimizers (combine and
> CSE can mostly work off of REG_EQUAL notes).  If you define_expand
> adddi3, they won't be able to handle loops using long long types.
> Whether this matters in practice for real code, I don't know.

My point was that I thought the interesting multi-word optimisations
(including loop optimisations) ought to be done at the tree level instead,
and that the main focus of the RTL optimisers ought to be optimising
things after machine-specific information has been exposed.  In contrast,
the MIPS define_insn & define_splits existed specifically to avoid
exposing machine-specific information to those optimisations.  I'm not
sure from your reply whether you disagree (although it sounds like you might).

> Certainly adddi3 and friends should not be straight define_insns, as
> they used to be for MIPS.  With the lower-subreg pass, they should be
> either define_expand to individual insns or define_insn_and_split with
> an unconditional split before reload.

Well, the old patterns had define_splits too.  I don't think that
was really the problem.

Richard