On Sun, 22 Jan 2012, Hans-Peter Nilsson wrote: > On Thu, 19 Jan 2012, BELBACHIR Selim wrote: > > > In fact my final purpose is to replace $INP by a register bank > > in order to be able to read several inputs using pipelined > > instructions (and instruction scheduler). The fixed reg solution > > will prevent me from doing this. Is there another way to prevent > > the use of some registers during the reload pass without turning > > them into fixed register ? > > I can't think of another way than to use different (narrower) > register constraints for the destination operand than the source > operands for the instructions which can take $INP as a source > operand, with the source operand register class to include the > register (sub)class for $INP, but this latter register class > must not be included in GENERAL_REGS nor of course the > destination register class.
And to clarify, the $INP register class would (only) be valid as a destination in the insns generated by the builtins that Ian suggested; but their expanders would not generate fixed registers. (You might trip some reload bugs, but those should just be bugs at least if you keep the move-cost for classes with those $INP registers greater than 2 and greater than other classes and possibly moves to/from memory. There, that should cover it.) brgds, H-P
