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). > 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