"Dmitry" <mittie@xxxxxxx> writes: > Ok. But what if the compiler uses that unnecessary clobber for a > branch or another CC dependent insn before reload, and if I remove > that clobber in a define_split after reload, could I end up with a > corrupted code? I'm sorry, I don't understand what you are trying to say. The compiler can't use a clobber. Simply removing a clobber can't cause corrupted code, because the compiler was already assuming that the value in the register was unpredictable. Ian > --- ÐÑÑÐÐÐÐÐ ÑÐÐÐÑÐÐÐÐ --- > ÐÑ ÐÐÐÐ: "Ian Lance Taylor" <iant@xxxxxxxxxx> > ÐÐÐÑ: "Dmitry" <mittie@xxxxxxx> > ÐÐÑÐ: 29 ÐÐÑÐÐÑ 2011, 19:52:44 > ÐÐÐÐ: Re: Back end question. > > > >> "Dmitry" <mittie@xxxxxxx> writes: >> >> > I have one more question. If I have, for example, a define_insn rtx which matches a pattern generated by previous define_expand rtx. define_expand and define_split combination produces either a simple "set" rtx or "set" plus clobber of CC reg. And if in define_insn I specify a constraint that requires such an operand type which should generate a CC clobber, but initially there could be a combination of operands that does not clobber a CC and also does not satisfy constraints, so compiler must reload one or two operands in appropriate registers which satisfies constraints. In the case those appropriate registers should clobber a CC does a compiler add a suitable clobber rtx as written in define_split, or it just changes the registers names without any knowledge of a necessary clobber? >> >> If I understand your question correctly, then the compiler is not going >> to add a clobber. Reload does not change the shape of the instruction. >> It just shuffles registers to match the constraints. If you have >> constraints which require a clobber, then the insn pattern should have a >> clobber. You can use define_split to remove an unnecessary clobber >> after reload is complete. >> >> Ian >> >>
