On Tue, 2010-03-16 at 15:12 +0800, Amker.Cheng wrote: > In my understanding, the macro GENERATE_MADD_MSUB is true when the processor > has > madd insn, rather than madd2. And the macro "ISA_HAS_<D>MUL3" is false if it > has > no mul insn. > > for this kind processor, gcc will > step 1 : generate insn using gen_mul<mode>3_internal, according to > pattern "mul<mode>3"; > step 2 : the combiner try to combine by matching against pattern > "*mul_acc_si"; > step 3 : it's possible that gcc fail to get LO register allocated for > the combined "*mul_acc_si" insn; > step 4 : after reload, the combined insn will be split according to > the split pattern listed in previous mail. > step 5 : the split insn is actually a "mul<mode>3_internal" , but get > no LO allocated, which break the > constraints in "mul<mode>3_internal" pattern;
OK. A much more complicated question than I realized. Yes, it does look like the mips port will fail in this case. As a practical matter, both mul and madd are MIPS32R1 and up instructions, so I would be surprised to see a processor that has the second one but not the first one. The new define_split you propose looks like it would work. Another possible solution is to take the mul_acc_si pattern and make two copies of it, one which tests ISA_HAS_MUL3 and one which tests ! ISA_HAS_MUL3. The first one remains the same. The second one drops the second alternative that has the 'd' destination. The reasoning here is that if splitting will result in worse code, then we shouldn't have accepted it in the first place. If dropping this alternative results in register allocator failures for some strange reason, then we accept it and generate the 3 instruction sequence with a new define_split. If dropping this alternative results in the register allocator generating worse code for other surrounding operations, then it is better to accept it and add the new define_split. Some experimentation might be necessary to see which change is the better solution. Jim
