[fpc-devel] x86_64 question

[J. Gareth Moreton]

So... I've done some tests, replacing TEST RCX, $4 with TEST CL, $4 and 
the like in a number-crunching function, and it seems to cause a notable 
penalty, even though none of the instructions are in my critical loop.  
So I think it's something that needs to be avoided in most cases.  I 
think the reason why it worked in my Int and Frac functions is because 
the processor knows the upper 48 bits of the register are zero.

Long story short... best not to do it unless you have some additional 
insight into what the registers contain.

Gareth aka. Kit


On 02/10/2020 08:15, J. Gareth Moreton via fpc-devel wrote:
> Ah brilliant, thank you.
>
> I have used Agner Fog's material before for cycle counting.  When I 
> implemented my 3 MOV -> XCHG optimisation 
> (https://bugs.freepascal.org/view.php?id=36511), I used Agner Fog's 
> empirical results to determine when it's best to apply this 
> optimisation where speed is concerned (on a lot of older processors, 
> it's not worth it because XCHG took 3 cycles and the 3 MOVs generally 
> took only 2 (due to how the dependency chain is set up).  Only when 
> XCHG's cycle count dropped to 1 or 2, or when optimising for size, 
> does it pay off.
>
> So it looks like a partial read of the lower bits is absolutely fine, 
> since you're not changing anything.
>
> Gareth aka. Kit
>
> On 02/10/2020 01:40, Nikolay Nikolov via fpc-devel wrote:
>>
>> On 10/1/20 11:36 PM, J. Gareth Moreton via fpc-devel wrote:
>>> I thought that might be the case - thanks Nikolay.  And I meant to 
>>> say lower bits of a REGISTER, not an instruction!
>>>
>>> Admittedly I'm cycle-counting and byte-counting again!  I was 
>>> looking for ways to reduce 13 bytes of padding in one of my pure 
>>> assembly language routines and realised I could make a saving 
>>> there.  The only thing I can think of that I have to watch out for 
>>> logically is if I change, say, TEST EAX, $80 to TEST AL, $80, the 
>>> latter will set the sign flag if the most-significant bit is 1 after 
>>> the 'and' operation) while the former always clears the sign flag.
>>>
>>> I have used such subregisters before in the FPC RTL, in fpc_int_real 
>>> and fpc_frac_real in rtl/x86_64/math.inc, where I read AX instead of 
>>> the larger RAX, but that's only after a call to "SHR RAX, 48" that 
>>> guarantees that everything above the 16th bit is zero, and after 
>>> testing other implementation candidates a kind of informal 
>>> competition. (Surprisingly, I think "shr $48, %rax; and $0x7ff0,%ax; 
>>> cmp $0x4330,%ax" runs faster than moving 64-bit constants into 
>>> temporary registers (since 64-bit immediates aren't supported 
>>> outside of MOV) and using 'and' and 'cmp' on %rax directly)
>>>
>>> I think you always get a read penalty when using the high-byte 
>>> registers because the processor has to do an implicit shift operation.
>>
>> I don't remember the reason, but I recall reading they are less 
>> efficient in Agner Fog's optimization manual. Here's the relevant quote:
>>
>> "Any use of the high 8-bit registers AH, BH, CH, DH should be avoided 
>> because it can cause false dependences and less efficient code."
>>
>> It's from the chapter "Partial registers" (page 61) of this document:
>>
>> https://www.agner.org/optimize/optimizing_assembly.pdf
>>
>> Highly recommended reading, as it addresses exactly the topic of 
>> partial registers. In general, it is the partial register writes of 
>> 16-bit or 8-bit subregisters that cause problems - either false read 
>> dependencies (usually on AMD) or extra penalties for 
>> joining/splitting registers (on Intel, at least in the P6 era).
>>
>> Best regards,
>>
>> Nikolay
>>
>> _______________________________________________
>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus