On Thu, 2010-03-18 at 19:20 +0800, Amker.Cheng wrote: > 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?
In theory, there should be no failure. In practice, maybe there will be. Lots of things in gcc are more complicated than they appear to be at first, and reload is the biggest one. The question in my mind is why does the mul_acc_si pattern have two alternatives? Maybe the second alternative was added as an obscure minor optimization. Or maybe it was added to fix an obscure register allocator failure. Without more info, it is impossible to know, and thus unsafe to make assumptions about which one is true. We may be able to find which one is true by looking at gcc history though. If we can find the ChangeLog entry and/or the patch that added the second alternative, that may tell us why the second alternative is there. > 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? Use the define_split method if dropping the alternative results in reload aborting, or if dropping the alternative results in code that is less efficient than the code you get with the define_split. > 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? Yes, that is another possibility. This makes the first alternative more desirable, and thus reduces the number of times the second alternative is chosen, but still allows the second one to be chosen in some cases when it might be better. This might even be a better solution than the first two we had. The only way to know is to do some experimenting, looking at assembly code to see what happens with the different choices. Jim
