Re: [MIPS] MADD issue

[Richard Sandiford <richard at codesourcery dot com>]

Ian Lance Taylor <iant@google.com> writes:
> Richard Sandiford <richard@codesourcery.com> writes:
>
>> 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).
>
> I suppose I neither agree nor disagree.  It's a matter for testing.
>
> It's clear that with our present scheme there are loop optimization
> opportunities at the RTL level in the form of hoisting new loop
> invariants created by expanding the addressing modes.  And, of course,
> some machines have specific loop instructions which currently can only
> be handled at the RTL level.

Right.  In case my message might be interpreted as saying that we
shouldn't have RTL loop optimisers, that wasn't the intention at all.
MIPS definitely benefits from them with %hi accesses, etc.  It was
more the opposite: splitting the instructions early ought to give
the RTL optimisers the opportunity to do more things that the tree
optimisers simply couldn't.  OTOH, trying to give the RTL optimisers
the same sort of arithmetic operations that the tree level had seems
like going out of our way to make the RTL optimisers repeat work.

> However, those should be more or less independent of adddi3.

Yeah, I hope so.

Richard