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.
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.
That's nice but can I rely on that behaviour? (As far as -O0 is concerned, I will emit the special insn just if optimization is turned on, but nevertheless it would be interesting to know why this works smooth with -O0 as I expected to run in unrecognizable insn or something like that during reload).
Yes, split1 (pass_split_all_insns in recog.c) runs at -O0 too. Paolo
