AES-GCM x86_64 MSVC ASM: XMM6-15 are non-volatile

[SparkiDev]

Description

Put XMM6-15, when used, on the stack at start of function and restore at end of function.

Fixes #6608

Testing

Standard

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[ilka1999]

Common mistake is the wrong offset for parameters which passed by stack.
These parameters are loaded before stack reservation for local purposes, so their offset should be the same, as it was before stack usage increase.

[ilka1999]

why +256 ?
it should be +96

[SparkiDev]

I use 20 64-bit words of stack in the function for temporary storage.

[ilka1999]

Sean,

It is loading parameters from the stack

Let's calculate offset for 5-th parameter:

1. first four parameters = 32 bytes
2. return address = 8 bytes
3. seven non-volatile registers saving = 56 bytes

totally 96 bytes
so, 5-th parameter has offset 96 from RSP

[SparkiDev]

Looks like I confused myself and treated the xmm registers to save as parameters.
Fix up now.

[ilka1999]

again why +264 ?

[SparkiDev]

As above, stack used for temporary storage.

[ilka1999]

why AVX version instead of SSE (movdqu) ?

[SparkiDev]

Good point.
Generated code and it didn't know to produce SSE2 only code.
Fixed this.

[ilka1999]

what about xmm8-14 ?

[SparkiDev]

Fixed generating code.

[ilka1999]

at least you need

1. change commands for all XMM saves from vmovdqu to movdqu
2. check the parameter offsets, they should not be changed unless there are no new stack modifications between the start of the function and the loading of the parameters.

be careful about addressing parameters from the middle of the code, it should be increased if such addressing occurs after new stack modifications

[ilka1999]

Sean,

It is loading parameters from the stack

Let's calculate offset for 5-th parameter:

1. first four parameters = 32 bytes
2. return address = 8 bytes
3. seven non-volatile registers saving = 56 bytes

totally 96 bytes
so, 5-th parameter has offset 96 from RSP

[SparkiDev]

Fixed generation to put on stack and take off stack in the right place.

[ilka1999]

Ok

Last version is working with my friend's tests

But, ASM code is not perfect:

1. there are some oddish lines
2. no proc frames

[SparkiDev]

Hi @ilka1999

1. Let me know what is odds in the lines. Specifics or generally.
2. Are you suggesting adding 'FRAMES' to the PROC lines?

Thanks,
Sean

[ilka1999]

IMHO:

1. the code still uses vmovdqu instead of movdqu
2. savings of XMM registers which does not changed
3. allocates stack for temporary local variables in the middle of body

I did not check the stack alignment of the code, with alignment you can use ALIGNED loading/store instead of UNALIGNED

[SparkiDev]

Hi @ilka1999,

Thanks for the feedback!

1. I've pushed an update to fix this.
2. This has also been fixed.
3. The temporary stack allocations are not something I intend to change right now.

Note that the stack is not always aligned as I would like. On newer processors, unaligned moves are the same speed as the aligned moves. I won't be making changes for this but thank you for bringing it up.

Sean

[ilka1999]

Tested successfully