[fpc-devel] generate assembler with no clear purpose MOV
margers.roked at inbox.lv
Tue Feb 4 22:15:59 CET 2020
----- Reply to message -----
Subject: Re: [fpc-devel] generate assembler with no clear purpose MOV
Date: otrd., 4 febr. 2020, 22:24
From: J. Gareth Moreton <gareth at moreton-family.com>
To: <fpc-devel at lists.freepascal.org>
> To hazard a guess, it's sign-extending to the CPU word size as an
> intermediate step. It's not something the peephole optimizer can easily
> eliminate. Do the register allocations give any clues before that
# Var k located in register ecx
# Var bit located in register esi
seems to be sign-extend, but if change variable "k" and "bit" to dword then there is simple movl %ecx,%edx.
Instruction SHLX (as well SHRX) is treated as variables always are memory variables and there for first read value in temp register and after write back. As well SHL and SHR are logical operators so no need for sign extension.
While those MOV instructions do not hurt much, there is benefit of resolving this issue - 2 or 1 free registers available for other purposes.
> On 04/02/2020 18:50, Marģers . via fpc-devel wrote:
> > p.s. tested execution speed and there is no measurable difference.
> >> asm code
> >> #  bit:= longint(1) shl k;
> >> movslq %ecx,%rdx
> >> # Register r8d allocated
> >> movl $1,%r8d
> >> # Register edx,edx allocated
> >> shlx %edx,%r8d,%edx
> >> # Register r8d released
> >> # Register edx allocated
> >> movl %edx,%esi
> >> # Peephole Optimization: %esi = %edx; changed to minimise pipeline stall (MovXXX2MovXXX)
> >> # Peephole Optimization: Mov2Nop 4 done
> >> what purpose serve: movslq %ecx,%rdx ?
> >> movl %edx,%esi seems unnecessary,
> >> when just enough would be
> >> movl $1,%esi
> >> shlx %ecx,%esi,%esi
More information about the fpc-devel