On Thu, Jan 12, 2023 at 09:17:31AM -0500, Paul Koning wrote: > > On Jan 12, 2023, at 4:50 AM, Segher Boessenkool > > <seg...@kernel.crashing.org> wrote: > > I mean general_operand accepts that sp thing you saw. But your > > constraints do not? (I don't know your target well, maybe this isn't > > true). Things like this should be sorted out by reload, but you get > > better code (and fewer problems ;-) ) if you make code that fits > > earlier. The L in LRA means "local": it "just" makes things fit, it > > does not emphasise optimising your code. > > The destination is "nonimmediate_operand" which matches what the machine > actually does. It's like VAX and M68k, instruction operands in general can > be registers, memory references, register indirect or memory indirect, memory > at register with offset, or autoinc/autodec off any register. > > As far as operand type is concerned, SP is certainly a valid operand for an > add operation, that isn't the problem. The problem is that it's a two > operand machine: the first operand of the add instruction is both source and > destination. And LRA assigned the source register to be the destination > register as required, but then after doing so it replaced the destination (an > FP reference) by a different register (SP reference), violating the > constraint after having satisfied it earlier.
Ah okay. Yes, something does not verify if the instructions are valid before doing some replacement. Something around ELIMINABLE_REGS it looks like? Maybe the dump file says more, or maybe the dump file can be improved. > Interesting to know what LRA stands for, I didn't know that. First line of lra.cc: /* LRA (local register allocator) driver and LRA utilities. :-) Segher
