> 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.
Thanks Jim. I could not get your method well since don't know much about the IRA and reload pass. Here comes the question, Does it possible that the method would ever result in register allocator failure? In my understanding, doesn't reload pass would do whatever it can to make all insns' constraints satisfied? > 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. By this , you mean I should go back to the define_split method if dropping the alternative does results in bad insns generated by RA? > > Some experimentation might be necessary to see which change is the > better solution. Yes, I profiled MiBench and found gcc generates better codes by using madd instruction; on the other hand, how bad the code is generated by define_split still not closely checked. Another thought on this topic, Maybe I should make two copy of mul_acc_si like you said, with one remains the constraints, the other drop the "*?*?". Does this is the same as your method suggested? -- Best Regards.
