Paolo Bonzini schrieb: > On 11/02/2010 10:41 AM, Georg Lay wrote: >> What I do not understand is*why* this works. >> The internals "16.16 How to Split Instructions" mention two flavours >> of insn >> splitting: One after reload for the scheduler and one during combine >> stage, the >> latter just doing single_set --> 2 * single_set splits for insns that >> do*not* >> match during combine stage. > > I think this is extremely out-of-date, I am sorry. I read something > from Ian Lance Taylor on the mailing list recently about the history of > splits. I cannot find it now, but basically the original purpose (help > combine to find matches for "big" patterns representing more than one > instruction) is now almost obsolete with define_insn_and_split, and the > split passes before and after reload have the biggest role in splitting.
You mean this? http://gcc.gnu.org/ml/gcc/2010-10/msg00444.html >> I observed that the insn gets split in split1 even if the splitter >> produces more >> than two insns and also if optimization is off. > > Yes, split1 does unconditional splitting of every define_split that > matches. Ok, so there is no way to re-feed the split insns into combine whilst insns that got split during combine will be reused by combiner, if I understand correctly. Anyway, many thanks for you explanations and your patience :-) Georg
