Re: [PATCH] wwwdocs: Note that old reload is deprecated

[Segher Boessenkool <segher@kernel.crashing.org>]

On Thu, Jan 12, 2023 at 09:17:31AM -0500, Paul Koning wrote:
> > On Jan 12, 2023, at 4:50 AM, Segher Boessenkool <segher@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