Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2021-02

Optimisation and memory alignment question

2 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

J. Gareth Moreton

Hi everyone,

So to get to the point, I've spotted another potential peephole optimisation specifically on x86_64:

    movq    (%rdx),%rax
    shrq    $32,%rax

Is it acceptable to change this to the following?

    movl    4(%rdx),%eax

Logically it's equivalent thanks to the guarantee that the upper 32-bits of the destination register will be zeroed, but I know sometimes there might be a penalty for reading from memory that isn't aligned to a 16-byte boundary, say.

A "movl; shrl $16" version may be possible with movzx, but I'm not certain if that will be even more inefficient due to the offset now being 2 rather than 4.

Gareth aka. Kit

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

Reply by email

Florian Klämpfl
to J. Gareth Moreton
J. Gareth Moreton wrote 11 lines
Hi everyone, So to get to the point, I've spotted another potential peephole optimisation specifically on x86_64:     movq    (%rdx),%rax     shrq    $32,%rax Is it acceptable to change this to the following?     movl    4(%rdx),%eax

Yes. If (%rdx) is naturally aligned (so to a 8 byte boundary), 4(%rdx) is at least aligned to a 4 byte boundary and thus naturally aligned.

Show quoted text 5 lines
Logically it's equivalent thanks to the guarantee that the upper 32-bits of the destination register will be zeroed, but I know sometimes there might be a penalty for reading from memory that isn't aligned to a 16-byte boundary, say.

x86 is very robust against misalignments and the example code is anyways naturally aligned. Everything above natural alignment is coincidence.

Show quoted text 8 lines
A "movl; shrl $16" version may be possible with movzx, but I'm not certain if that will be even more inefficient due to the offset now being 2 rather than 4. Gareth aka. Kit

Reply by email