Miles Bader <[EMAIL PROTECTED]> writes: > I've defined SECONDARY_*_RELOAD_CLASS (and PREFERRED_* to try to help > things along), and am now running into more understandable reload > problems: "unable to find a register to spill in class" :-/ > > The problem, as I understand, is that reload doesn't deal with conflicts > between secondary and primary reloads -- which are common with my arch > because it's an accumulator architecture. > > For instance, slightly modifying my previous example: > > Say I've got a mov instruction that only works via an accumulator A, > and a two-operand add instruction. "r" regclass includes regs A,X,Y, > and "a" regclass only includes reg A. > > mov has constraints like: 0 = "g,a" 1 = "a,gi" > and add3 has constraints: 0 = "a" 1 = "0" 2 = "ri" (say) > > So if before reload you've got an instruction like: > > add temp, [sp + 4], [sp + 6] > > and v2 and v3 are in memory, it will have to have generate something like: > > mov A, [sp + 4] ; primary reload 1 in X, with secondary reload 0 A > mov X, A ; "" > mov A, [sp + 6] ; primary reload 2 in A, with no secondary reload > add A, X > mov temp, A > > There's really only _one_ register that can be used for many reloads, A.
I don't think there is any way that reload can cope with this directly. reload would have to get a lot smarter about ordering the reloads. Since you need the accumulator for so much, one approach you should consider is not exposing the accumulator register until after reload. You could do this by writing pretty much every insn as a define_insn_and_split, with reload_completed as the split condition. Then you split into code that uses the accumulator. Your add instruction permits you to add any two general registers, and you split into moving one into the accumulator, doing the add, and moving the result whereever it should go. If you then split all the insns before the postreload pass, perhaps the generated code won't even be too horrible. Ian
