Richard Sandiford <[EMAIL PROTECTED]> writes: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > Richard Sandiford <[EMAIL PROTECTED]> 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. However, those should be more or less independent of adddi3. Ian
